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ABSTRACT 


Functional programming languages incorporate a number of powerful features, 
including advanced polymorphic type systems and first-class, higher-order functions. 
However, these important features have had little impact on popular imperative languages 
such as C. As part of the Advanced Type Systems Project at NPS, a dialect of C called 
Polymorphic C has been designed that integrates an advanced polymorphic type system 
into C. 

In order to implement full parametric polymorphism while retaining the run time 
efficiency of C, it is necessary to allow mixed data representations. We recommend 
adopting a variant of the program translation methods first proposed by Leroy to 


implement mixed data representations in ML for use in Polymorphic C. 
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I. INTRODUCTION 


Chapter I is divided into five sections. Section A introduces the functional 
programming paradigm and discusses the directions and some obstacles faced by 
researchers in the field. Section B is dedicated to concepts and definitions necessary to 
the entire scope of the thesis. Section C discusses some software engineering issues 
motivating research into polymorphic expression. Section D contrasts C and C++ with 
functional languages and discusses several ways in which C/C++ can be improved. 
Section E concludes the chapter with a brief introduction to Polymorphic C, a 
polymorphic imperative language being developed as part of the Advanced Type Systems 
Project at the Naval Postgraduate School and Florida International University [SmVo95]. 


A. FUNCTIONAL PROGRAMMING LANGUAGES 

Much work has been done in the past decade on the development of advanced 
programming languages, particularly functional languages such as SML/NJ, Haskell, 
Miranda and Napier88. Functional languages all share the common paradigm that 
function application is the primary method used for computation. This paradigm can be 
contrasted to that of imperative languages such as Ada and C/C++, where the primary 
method of computation is the manipulation of variables. In addition, functional 
languages also exhibit a number of advanced features, such as mathematically rigorous 
semantics, polymorphic typing, higher-order functions, unrestricted first-class values and 
partial application of functions. 

For many years, functional languages were of interest only to researchers. ML, 
for example, was designed as the metalanguage for the Logic for Computable Functions 
verification system. However, in the past few years researchers have initiated several 
attempts to demonstrate the efficacy of these languages in the development of real-time 


systems, systems-level programming and/or rapid prototyping. 











As noted in both [HaL94] and [HuJ94], the application of functional languages to 
large, real-world problems shows great promise due to the flexibility and structure of 
functional languages. In one prototyping study [CHJ94], the functional programming 
language Haskell was shown to be significantly superior to both C and Ada in ease of 
programming for a real-world geometric server application. The primary factors in the 
success of Haskell appear to be the effective use of polymorphic, higher-order functions, 
partial application of functions and functions as first-class values. 

Implementing the advanced features of these is challenging. To support 
polymorphic functions, an implementation of a language must adopt some form of data 
representation that allows a given computational object to assume values of many 
different types. For example, a compiler may not statically assign the result of a 
polymorphic function to a floating point register if that result may be of type other than 
float. By the same token, if the result is of type float, it may be inefficient to represent it 
uniformly and place it in a general purpose register. 

Various language implementations have adopted different methods to deal 
polymorphic functions. For example, SML/NJ uses a uniform data representation (heap- 
allocated pointers) for all objects. While the scheme works, the need to continually 
reference and dereference pointers is obviously inefficient. Other languages use different 
schemes. 

The focus of this thesis is to review several promising methods used to efficiently 
implement polymorphic functions and to propose possible methods for the efficient 


implementation of Polymorphic C. 


B. CONCEPTS AND DEFINITIONS 


We begin by providing some background information. 


L: Type 
Types in programming languages loosely correspond to sets. In set theory every 


entity is either an element of a set or is a set of either elements or other sets. When 











considering the universe (i.e., the set of all sets) within the context of a given domain it is 
natural to organize it in different ways for different purposes. Types arise naturally in 
such a classification effort as sets of entities which exhibit common usage and behavior. 
In computer science, a fype is a set of computational objects with uniform 
behavior. For example, any object of type integer can be expected to observe the total 
ordering one expects from the set of integers. Likewise, any object of type even_integer 
(a sub-type of type integer) can be expected to be congruent to 0 (mod 2). Declaring an 
object to be of a certain type is a declaration of membership in some appropriate set or 


subset of interest and, indirectly, a declaration of the behavior of that object. 
Z. Monomorphic / Polymorphic Type Systems 


Functions and procedures in conventional languages such as Ada are 
monomorphic, meaning that each can be called with exactly one type. To illustrate, 


consider the Ada implementation of the integer identity function shown in Figure 1. 


function identity(value: integer) return integer is 
begin 


return value; 
end; 





Figure 1. Monomorphic Identity Function in Ada. 


This function operates on an integer and returns an integer and is itself a 
computational object which can be typed. In this case, itis oftype int -> int, read 
as “mapping from an integer to an integer”. As a result, the compiler will allow this 
function to be applied only to objects of type int. If an equivalent function was required 
for a different type (e.g., floats), a separate identity function would have to be written and 


compiled for that type. 








In this case, however, the behavior of the function is entirely independent of the 
type of it’s actual parameter. This is the case in many useful functions. One frequently 
cited example is a linked list of records, where the act of appending a record to the end of 
the list 1s entirely independent of the types of it’s various fields, except for the one field 
that contains a “next” pointer. Another example is a function which reverses the order of 
the elements 1n an array; the functionality provided by the function is independent of the 
type of the array elements. 

By contrast to monomorphic languages, other languages such as ML allow 
functions to have more than one type; these languages are said to be polymorphically 
typed, or polymorphic. The identity function, and an application of it, can be written in 


ML as shown in Figure 2. 


val identity = (fn x => x); 


val three = identity(3); 





Figure 2. Polymorphic Identity Function in ML. 


The syntax in this case is straight forward; the identifier identity is bound to 
the function which takes a parameter x and returns x. This function is a mapping from an 
object of any type to an object of the same type. The type of the function is written as o 
~> a, where o is a type variable representing any type. This function can therefore be 
applied to any type and needs to be written and compiled only once. 

Also of note in Figure 2 is the complete absence of explicit type information. 
Nonetheless, ML’s type inferencing system is able to correctly deduce the type of the 
value assigned to three. Since the function is of type a —> a, and the actual parameter 
is of type int, then a must equal int. That means, in turn, that the return value must be 


of type int and three must be of type int, since that value is being assigned to 














three. This sort of type inferencing is not necessarily unique to polymorphic 


languages. 


3. Strongly Typed Languages 
One of the primary goals for anyone designing or implementing a language, be it 
monomorphic or polymorphic, is to prevent a class of error known as type violations. A 


simple example is given in the ML program shown in Figure 3. 


val successor = (fn x => x + 1); 


val three = successor(3.0); 





Figure 3. Example of Type Violation. 


In Figure 3, the integer successor function, successor is defined. Because the 
right-hand operand of the addition operator is of type int, the type of successor is 
inferred by the ML type inference system as being of type int -> int. This function, 
then, is monomorphic; it operates only on integers. 

However, the subsequent call to successor attempts to pass to successor a 
value of type real. This is a type violation; the program’s behavior would be 
unpredictable if a compiler were to allow such errors in the general case. It is unclear, for 
example, what the successor function should do if passed an object of type list or, for 
that matter, of type automobile. Languages that strictly avoid such type violations are 


said to be strongly typed. 


4. Static vs. Dynamic Typing 
To prevent type violations, one can impose a static type structure on a program. 


Types are associated with all expressions (i.e., constants, operators, variables and 





functions) in the program. Subsequent analysis of the program can then determine 
whether type violations might arise during execution. 

Sometimes, however, binding expressions to specific types at compile time is too 
restrictive. This is certainly the case in a polymorphic language, where a given 
expression (e.g., a polymorphic function) might assume an arbitrary number of types 
during program execution. In this case, a polymorphic language might only require that 
expressions are guaranteed to be type consistent. For example, if a particular application 
of a polymorphic function returns an integer, then that return value should ultimately be 
assigned only to expressions of type integer. 

If the type of each expression can be deduced, or type consistency confirmed, at 
compile time (i.e., statically) the language is said to be statically typed. This a useful 
property for reasons of efficiency. For example, if the compiler can deduce that the value 
returned from function foo is of type real, it can place that value in a floating point 
register vice a general purpose register. Subsequent floating point operations on that 
value can be performed without first moving the value to an appropriate register. 

On the other hand, some languages, primarily object-oriented languages such as 
Smalltalk, adopt a policy where only the values are assigned a unique type. Variables 
and parameters may take values of different types at different times. Because of this, the 
values of operands must be checked immediately before the execution of any operation. 
Such languages are said to be dynamically typed. [Wa90]. 

A language may remain strongly typed regardless of whether it 1s statically or 
dynamically typed. The decision to make a language statically or dynamically typed is a 
design decision orthogonal to making it strongly typed (which is always preferable) and 
is beyond the scope of this thesis. Polymorphic C is a strongly and statically typed 


language. 














5: Classification of Polymorphic Forms 
Cardelli and Wegner have classified several varieties of polymorphism [CaW85]. 
In their scheme, there are two major types of polymorphism, universal and ad hoc, each 


of which is further subdivided. This classification scheme is described below. 


a. Universal Polymorphism 

Functions which exhibit universal polymorphism will generally work on 
an infinite number of types. Such procedures are universally quantified on the types of 
their arguments. In other words, expressing the type of the polymorphic identity function 
as being of type « —> o is merely a short-hand way of stating Va.(a —> a), which is read 
as “for all values of type a, the function accepts a parameter of type o and returns a value 
of type «”. For this reason, formal parameters of type a are often referred to as 
quantified parameters. 

Stated in terms of implementation, a universally-polymorphic procedure 


will execute the same code regardless of type. 


(1) Parametric Polymorphism. In parametric polymorphism, a 
polymorphic function has an implicit or explicit parameter which determines the type of 
the argument for each application of that function. Functions that exhibit this form of 
polymorphism are called generic functions. These functions generally do the same sort 
of work independent of the argument type. The polymorphic identity function is one 
example. The list reversal function shown in Figure 4, is another, as the work performed 


by the function is independent of the type of the list elements. 


fun reverse (({]) = [] | 


reverse (H::T) reverse(T)@{H]; 





Figure 4. List Reversal Function in ML. 





It is worth noting that Ada’s generic functions are a special case of 
parametric polymorphism. The ML list reversal function is compiled only once and will 
then operate correctly on lists of any type. An equivalent generic Ada function is not 
directly executable; rather, it must be instantiated statically for each type of interest 
creating, in effect, a set of functions with identical functionality but each operating on 
lists of a specific type. 

Function templates in C++ are also a special case of parametric 
polymorphism. They are slightly different from Ada’s generic functions, however, in that 
the instantiations for parameters of different types are performed implicitly (i.e., by the 
compiler vice the programmer). At run time one version of the function exists for each 


parameter type of interest, as in Ada. 


(2) Inclusion Polymorphism. Inclusion polymorphism was 
introduced to model sub-typing and inheritance. As such, it is the type of polymorphism 
generally referred to when discussing object-oriented languages. In this form, an object 
can be viewed as belonging simultaneously to many different types, or classes. 

In particular, an object of a derived class can be used whenever an 
object of a base (ancestor) class is expected. For example, the integer 17 can be viewed 
simultaneously as a prime integer, an odd integer and an integer between 10 and 20. 
While inclusion polymorphism is interesting in it’s own right, Polymorphic C does not 
support object oriented features such as classes and inheritance and, so, the issue is 


tangential to the thrust of the discussion. 


b. Ad Hoc Polymorphism 
Ad hoc polymorphism is obtained when a function works on several 


different types but may behave in different, perhaps unrelated, ways for each type. 


(1) Overloading. In overloading, the same identifier is used to 


denote different functions. Any ambiguity is resolved explicitly or implicitly based on 














the context of the function call. As such, it is purely a syntactic convenience for the 
programmer. 

A pervasive example is the use of the “+” operator. It denotes 
integer addition, floating point addition and, in some languages, string concatenation. In 
languages which allow the programmer to overload predefined operators, it could 
potentially mean anything at all. In any case, in successive applications on values of 
different types, a separate monomorphic function tailored to that type is invoked to do the 
work. 

It should be noted at this point that the generic functions found in 
Ada, noted earlier to be a special case of parametric polymorphism, can also be 
considered as simple overloaded functions. The precise classification (if one is required) 
depends on one’s point of view. At the source code level, generics exhibit parametric 
polymorphism; one piece of source code suffices for an unlimited number of types. At 
the object code level, generics exhibit polymorphism based on overloading; a separate 


piece of code is executed for each type, depending on context. 


(2) Coercion. Coercion allows the programmer to omit 
semantically necessary type conversions; the required conversions are inferred by the 
compiler and inserted into the code. For example, in writing the C code char b = 
‘a’ + 1; the programmer would be exploiting the fact that the machine representation 
for characters (the familiar ASCII mapping) can be meaningfully interpreted as a integer 
and that the result of the integer addition can, in turn, be meaningfully re-interpreted as a 
character. The same result could have been achieved by making the coercions explicit, as 
follows: char b = (char) ((int)’a’ + 1); 

As will be seen in later chapters, explicit coercion, also known as 
type casting, is an important tool in the implementation of parametric polymorphism. 
This point is worth making early. The concept of parametric polymorphism and the 


implementation of parametric polymorphism are distinct issues. 











c. THE ROLE OF POLYMORPHISM IN SOFTWARE ENGINEERING 
Apart from pure theoretical interest, polymorphic functions have some pragmatic 
utility to the field of software engineering, particularly when dealing with large 
organizations and/or large programming projects. The motivation for polymorphic 
functions are discussed here in the context of two software engineering goals - program 


correctness and code reuse - and the common obstacle to each. 


1. Goals 

The need for polymorphic expression in programming languages derives from two 
important but conflicting goals in the field of software engineering; the ability to prove 
statically the correctness of a program and the ability to reuse programs or program 


segments which are known to be correct. 


a. Program Correctness. 

Much of the work of proving a program correct has nothing to do with 
language design or implementation. Certain classes of errors (e.g., faulty requirements 
specification, errors in logic) cannot be addressed easily, if at all, at the level of language 
design. Other classes of errors, however, such as type violations, can be detected and 
prevented. 

The compiler for a statically typed language can evaluate a program and 
guarantee that all expressions are type consistent. In a large programming effort this 
facility is extremely beneficial as separate programmers inevitably introduce new types 
and/or new variables,. The cost of discovering a type error at run time can be several 
times as expensive as discovering it at compile time, and is even more expensive if 


discovered after product delivery. 


b. Code Reuse 
The desirability of code reuse - the ability to write routines for a 


potentially unlimited set of applications - is obvious in the context of a large organization 


10 











and/or a large software development effort. Of particular interest are those routines 
which can be reused when new data types are defined. 

An Ada generic sort routine serves as a slightly anemic example of this 
ability. Ada generics serve merely as templates for the construction of specialized 
executable code and are, as such, reusable only at the source code level. To use sucha 
routine, the programmer must specifically instantiate a specialized version of it for each 
data type of interest. 

Thus, while there will exist some improvement in programmer 
productivity, the executable may contain many sections of machine code with identical 
functionality. In addition, each of these sections would have to be re-compiled for each 
project. A solution whereby both source and machine code could be reused without 


duplication - and perhaps without recompilation - would be preferable. 


Z. Obstacles 

Static typing tends to prevent code reuse while reusable programs are harder to 
statically type check. A monomorphic routine to sort integers, for example, is easy to 
type check but could not subsequently be used to sort strings. At the same time, in the 
absence of a strongly typed polymorphic type system, a reusable routine to sort elements 
of an unspecified type might easily be used (misused) on almost any data structure, 
however inappropriately. 

Polymorphic type systems try to reconcile these two goals by providing all of the 
type safety of a statically-typed monomorphic language and most of the code re-use 


flexibility of an untyped language [Car84]. 
D. C/C++ 

Despite the many powerful features of functional languages, they are unlikely to 
fall into widespread general use. Languages such as C are extremely popular and already 


very capable in the domain of real-world, systems-level programming. It is unlikely that 


a significant number of organizations would discard the enormous investment of 
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resources in tools and programmer training in favor of any current functional language. 
A more pragmatic approach might be to incorporate the results of research in functional 
languages into imperative languages such as C and C++. 

Specifically, one might improve C/C++ in the following ways: (1) more rigorous 
type checking, (2)more robust polymorphism and (3) the implementation of first-class, 
higher-order functions. 


1. Type Checking 

Despite claims to the contrary [Str91], C/C++ too often behaves as a 
weakly-typed language. C incorporates an unrestricted coercion mechanism, where by a 
value of one type is automatically interpreted as belonging to another type whenever 
necessary and possible. Consider the C++ program in Figure 5. 

Here, the function identity is the monomorphic integer identity 
function with type int -> int. Function main then invokes the identity function 
with two separate non-integer values. The output is as follows: 


xe <2 
Y:: “69 
Clearly, this program is incorrect. The value 2.9 was coerced to an integer 


representation (by truncation), while the character ‘A’ was coerced to it’s integer ASCII 
representation. An ardent C/C++ programmer might argue that implicit coercion of this 
form (“in the right hands”, of course) is a feature vice a deficiency. However, some 

programs are not “in the right hands” and the detection of precisely this class of error is 


why type checking has been so useful in programming languages. 


a# More Robust Polymorphism 

C is amonomorphic language. C++ is termed a polymorphic language, 
but the form of polymorphism is more anemic than found in most functional 
programming languages. C++ provides function and class templates and, like all other 
object-oriented languages, allows inheritance between classes. These are legitimate 


forms of polymorphism, however, extending C++ to allow for ML-style parametric 
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polymorphism would allow for much greater flexibility in coding and far greater ease in 


code reuse. 


int identity(int value) {return value; } 


void main() 
{ 
ant X= LGEnti ty (2.9) > 
cout << “xX: “ << XK << endl; 


int Y = identity(‘A’); 
CoOut. << “Ye & << Y- 





Figure 5. Application of Monomorphic Identity Function in C++. 


The traditional method of achieving parametric polymorphic expression in 
C/C++, namely the use of pointers to type void, is instructive. In Figure 6, the identity 
function, id, is declared as one which takes a pointer to void and returns that pointer as a 
result. As such, id can be viewed as a polymorphic function of type a -> a. Before 
calling the function, it’s parameters are referenced and the resulting pointers are cast as 
pointers to void. Following the call, the returned pointer is cast to it’s proper type and 
dereferenced to obtain the required value. 

Two points are worth making in advance. First, the pointer returned from 
id can be interpreted in any way, including an inappropriate way, as seen in the last call 
to id in Figure 6, where the result of passing a character to the identity function is cast as 
a float. 

Second, this general mechanism - converting an object to some uniform 
representation before a function call then carefully reconverting it to its regular form after 


the call - is exactly the conceptual scheme (with some refinements) used by many 
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functional programming languages to implement parametric polymorphism. The 
implementations of these languages eliminate the need for explicit casting on the part of 


the programmer. 


void* id(void* x) {return x; } 


void main() 

{ 
int i = 123; 
char c ‘A’; 
float: £ = 12344; 


t 


int intResult (ant™) (1d ((void*) &1) 


i ) 
char charResult *(char*) (1id((void*) &c) ); 
* ) 


float floatResult = 


7 


(float*) (id((void*) &£) 


float badResult *(float*) (id((void*) &c)); 





Figure 6. Emulating Parametric Polymorphism in C. 


3. Higher-Order Functions and First-Class Functions 

Functional languages treat functions as first-class values. As such, they 
can be passed as parameters, returned as function results, be included in composite 
values, and so forth, and are referred to as first-class functions. A first-order function 1s 
one whose parameters and result are non-functional. By contrast, a higher-order function 
is one which can take another function as a parameter and/or return a function as a result. 
[Wa90]. 

C/C++ treats functions as first-order, second-class values and can be 
improved by allowing functions to be expressed as higher-order, first-class values. 
Consider the ML code in Figure 7 which shows a common use of higher-order, first-class 


functions to apply a given function to each element in a list. 
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fun map (f, nil) = nil 


map (f, head::tail) £(h)tsmap(£, tazl); 





Figure 7. Example of Higher-Order Function in ML. From [St92]. 


The function map is very interesting and is indicative of the style and 
power of functional languages. First, though, a brief description of the syntactic elements 
is needed. The keyword nil signifies the empty list. The symbol “: :” is the list 
catenation symbol with the identifier to the left of the symbol representing the element at 
the head of the list and the identifier to the right representing the rest of the list. In other 
words 1::[2,3] =[1, 2, 3]. The symbol “|” simply means “or”. 

The function map, then, is defined as the function that takes as a parameter 
a function and a list and returns a list. The list may be empty, in which case it is returned. 
The returned list is computed by applying the supplied function to the element at the head 
of the list and appending the result to the front of a new list returned by a recursive call to 
map on the tail of the list. 

Several things are of note in this example. The first is the relative ease 
with which a function of this sort can be expressed once one is familiar with the style and 
syntax. This occurs relatively naturally as a result of the Prolog-style pattern matching 
used in ML expressions. 

The second is the complete absence of explicit type information. In this 
case, the function is both completely polymorphic and completely type consistent. Based 
solely on the structure of the function, the ML type system is able to deduce that map is 
oftype(a -> B) * a list -> B list. As such, it takes as arguments a function 


oftypea -> Banda list oftype a list and returns another list oftype B list. 
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An application of function map might be as shown in Figure 8 with the result newList 


= [2, 3, 4] oftypeint list. 


fun successor 


val intList (Ty 2 pols 


val newList map(successor, intList); 





Figure 8. Application of Function Map. 


The function successor is the integer successor function defined in 
ML’s functional notation; it is read as “bind the identifier successor to the function 
which takes a parameter x and returns the value x + 1. Because of the integer literal in 
the function body (x + 1), the type system is able to determine that successor is of 
type int -> int. In the context of the type assignment for map, then, a = B = int. 

In the second line, the identifier int List is declared and defined using a 
list aggregate as a list with elements of type int ({] are ML’s list construction 
operators); itis assigned the type int list. 

The application of map, then, isoftype (int -> int) * int list 
-> int list, which is completely consistent with both our expectations and the 
quantified type assigned to the function map. 

In C/C++, however, the only two things one may do with a function are a) 
call it or b) take its address [Str91]. To avoid the complexity associated with 
manipulation of lists (which are not a base type in C++) let’s consider a simpler example. 
The ML and C++ versions of the monomorphic higher order function, HOF, are shown in 
Figure 9. 

The ML code is relatively straight forward. As in the case of the function 


map, the programmer is allowed to operate at a relatively high level of abstraction. 
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The C++ code, on the other hand is much more tedious and error prone in 
that the programmer is not allowed to abstract away from the underlying mechanisms of 
the language. In this case, since functions are not first-class values, the programmer must 
explicitly declare a new type, INT2 INT, representing a pointer to a function of type 
int -> int. Function HOF is then defined as one which takes a pointer to a function 
of type INT2INT and an integer. The function is then applied, via the pointer, to the 
integer. 

Of note is that the C version of HOF is not truly higher-order since neither 
of it’s arguments are functions; it only simulates the behavior of a higher-order function. 
Also, although type information has been supplied explicitly throughout the routine, in 
the end, type errors of the class described earlier (e.g., int theInteger = ‘A’)are 


still not prevented due to C’s unrestricted coercion mechanism. 


fun Double (x) x * 23 

fun HOF (f, x) £ (x); 

val DoubleInt = HOF(Double, 3); 
int Double(int x){return x * 2;} 


typedef ant (*INT2INT) (int) ; 


int HOF(INT2INT £, int x) {return £ (x) ;} 


int DoubleInt = HOF(Double, 3); 





Figure 9. Comparison of Higher-Order Functions in ML and C++. 


Simulating polymorphic higher-order functions equivalent to the ML map 


function are even more difficult in C. Doing so requires frequent referencing and 
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dereferencing, casting and recasting, in order to achieve the same results as are achieved 
without effort in a functional language. Specific examples are given later. 

One further benefit of higher-order functions is worth mentioning. In 
addition to accepting functional arguments, higher-order functions can also return 
functional results. This leads to the potential for huge benefits in expressiveness and 
programmer productivity. One can imagine setting out to build a library of trigonometric 
functions, for example. After carefully designing and testing the function sin (x), one 
could then simply define cos (x) as follows: cos(x) = sin(x+90). 

Hudak and Jones have reported significant success using this type of 


approach in large, real-world problems [HuJ94}. 


E. INTRODUCTION TO POLYMORPHIC C 

The following introduction to Polymorphic C borrows heavily from the initial 
paper on Polymorphic C, [SmVo095]. 

Polymorphic C is a polymorphic dialect of C. It is designed to be as close as 
possible, semantically, with the original K&R C [KR78]. As such, it is stack-based with 
pointers, variables and arrays. Pointers are first-class values and can be explicitly 
dereferenced. Variables are second-class values and are implicitly dereferenced. It has 
the same pointer operations as C, namely the pointer dereferencing operator (*), the 
address of operator (&) and pointer arithmetic. 

Unlike C, it incorporates an advanced polymorphic type system similar to those 
found in functional programming languages and allows first-class, higher-order functions. 
And, unlike functional languages, the type system also addresses the polymorphic typing 
of pointers. The combination of these enhancements results in a language with the 
flexibility of C and the natural, type-sound polymorphism of ML. 

To accomplish this result, the designers imposed one key restriction: “The free 
identifiers of any lambda abstraction must be declared at top level”. Informally, this 


means that any object used by a function must be either local to the function (i.e., bound 














to the function abstraction and having a lifetime that ends upon return from the function) 
or global (i.e., declared at top level). 

The internal static variables of C are an example of the first type of violation. 
They are declared locally but persist after return from the function. Polymorphic C, then, 
does not support internal static variables; rather, they must be replaced with uniquely- 
named global variables to achieve the same functionality. 

The second type of violation can occur when function declarations are nested. 
This violation cannot occur in C but, for the sake of completeness, Figure 10 gives a 
sample Ada program which highlights this type of violation. Inside foo a variable 
foo_x is declared and initialized. Then, also inside foo, the function bar is declared. 
Function bar uses the variable foo_x (which is visible to it) in it’s body. 

In this case, the variable foo_x is free in function bar but is not global. This is 
an example of the second type of violation of the restriction on lambda abstractions in 
Polymorphic C. 

Beyond these simple examples, the restriction on lambda restrictions has only one 
other consequence. Most functional languages allow partial application (currying) of 
functions; Polymorphic C does not allow curried functions. Since this issue is tangential 
to the implementation of polymorphism, it is included here only for completeness and 
will not be discussed further. 

The only other issue of immediate interest deals with the passing of parameters. 
In most imperative languages, as in C, the formal parameters of a function are local 


variables. In Polymorphic C they are constants. 
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procedure foobar is 
function foo return integer is 
foo x: integer := 123; 
function bar return integer 
begin 
return 2 * foo x; 


end; 
begin 
return bar; 
end; 
begin 
put.(£oo) ; 
end; 





Figure 10. Violation of Polymorphic C Restriction on Lambda Abstractions. 


20 








Il. IMPLEMENTING POLYMORPHISM 


Chapter I, Section B, discussed the various types of polymorphism, which is 
generally categorized as either universal or ad hoc. Universal polymorphism is further 
categorized as either parametric (generic) polymorphism or inclusion polymorphism; ad 
hoc polymorphism is further categorized as either overloading or coercion. 

This chapter begins with a review of three techniques for implementing 
polymorphism: textual polymorphism, uniform polymorphism and tagged 
polymorphism. These terms are unfortunate 1n that they seem to be additional forms of 
polymorphism but they are not. Rather, they are general techniques for implementing 
polymorphism. 

As seen earlier, the precise meaning of polymorphism in a system is interpreted 
with respect to a given level of abstraction. For example, Ada’s generic functions could 
be viewed a special form of parametric polymorphism because the source code was 
independent of the type of the parameters and return values. At the same time, they could 
be viewed as a special case of overloaded functions since the underlying machine code 
was dependent on type. 

When discussing the implementation of polymorphism, it is necessary to first 
define the level of abstraction at which one is operating. [MDCB91] takes a pragmatic 
approach to this issue by defining the possible levels of abstraction based on whether or 
not the source code, machine code and/or underlying store representations are dependent 
on data type. Table 1 outlines the sensible combinations. 

In order for any polymorphism to exist, the source code of the program must 
contain expressions which are independent of datatype. If this is the limit of 
polymorphic expression in an implementation, it is termed textual polymorphism. If both 


source and machine code are independent of data type, but store representations may be 
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Table 1. Levels of Abstraction for Implementing Polymorphism. 








different for each data type, it is termed tagged polymorphism. If source code, machine 
code and store representations are all independent of type, it is termed uniform 


polymorphism. Each of these is discussed separately in following sections. 


A. TEXTUAL POLYMORPHISM 

In order for any polymorphism to exist, the source code of the program must 
contain expressions which are independent of the type of data. If this is the limit of 
polymorphic expression, it is termed textual polymorphism. A generic function in Ada, a 
C++ template and an overloaded “+” operator are all examples of this form of 
implementation. 

Since textual polymorphism applies only to source code, the compiler is free to 
generate optimum code and optimum data representations for each of the specializations 
of the function. For example, the polymorphic identity function Ax . x might be invoked 
with parameters of three different types within a given compilation unit (e.g., x: int, 
x:string, x:empRec). A textual polymorphic implementation would generate three 
specialized functions, A(x:int) .x, A(x:string).x andA(x:empRec) .x; the 
function that is actually called would be determined statically from the context of the call. 

The space overhead associated with this implementation technique can be quite 


severe. Within a given compilation unit there are significant space inefficiencies if 
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several large procedures must each be specialized for many different types. Even worse 
is the case of separate compilation, where the number of types is not known statically. 

[MDCB91] notes that, within a compilation unit there is an upper bound on the 
number of specialized forms that must be generated. In theory, this number could be 
quite large. If a function takes p quantified parameters, each of which might be of n 
possible types, there are n? possible specializations. For example, the function 
A(x:a, y:B, z:x)-.{[x, y, z], which takes three quantified parameters x, y, and 
z of types a, B, and y, respectively, and returns a record of three fields containing the 
values of those parameters, would have n° possible specializations, where n is the number 
of types in the system. 

In practice, the compiler would have to generate, at most, one specialized form of 
the procedure for each static call. Some of these would share representations, further 
limiting the number of specializations required. However, this would not be the case for 
separate compilation. Since the context of the call would not be known statically, the 
compiler would have little choice but to generate all possible forms of specialization. 

The complexity of the problem can also become significantly greater in the case 
of conditional function calls or in the case where a polymorphic function are passed as 
parameters to other functions. Consider the Napier88 code of Figure 11. 

A polymorphic procedure, first, quantified on types a and b, is defined as one 
which takes as parameters W of type a and X of type b. The ellipses indicates some 
arbitrary procedure body. Then another polymorphic procedure, second, is similarly 
defined; it is quantified on types s and t, and takes two parameters, Y and Z of those 
types, respectively. Inside the body of second exists a conditional. Depending on the 


truth value of condition, the procedure first is called in one of two ways. 





let first = proc[a, b] (W:a; X:b) 
Lét: second = proctitis, TG) (Yes). 27t) 


if <condition> then first[s, t](Y, 2) 
else first[t, s](Z, Y) 





Figure 11. Exponential Expansion of Code. After [MDCB91]. 


In this code fragment, for each call of second, there are two possible calls of 
first. Since the truth value of condition is not known statically, two 
specializations of first are required for each specialized call to second. The total 
number of specialized forms is found by multiplying the number of different 
specializations in the call chain. Introducing the procedure third, shown in Figure 12, 
would cause four specializations of first to be generated for each specialization of 
third (two specializations of second and, for each specialization of second, two 


specializations of first). 


let third = proc[x, y, Z](X:x, Y:y, 4:Z) 


if <condition> then second[x, y] (X, Y) 
else second{ly, 2] (Y, 2Z) 





Figure 12. Multiplicative Expansion of Code Due to Call Chain. 


Passing polymorphic procedures as parameters also introduces a multiplicative 
growth in code, though to a lesser extent. The Napier88 code fragment of Figure 13 
illustrates this. 
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let id proc(uj (Xi Woe=> uu); x 


jet foo prec|s] (yis; Dar: proc(t).t => 2) >: is) 
bar[s] (y) 


let oneTwoThree = foo[int] (123, id) 





Figure 13. Multiplicative Growth of Code Due to Polymorphic Higher-Order Functions. 


The syntax and structure of the Napier88 code in Figure 13 requires some 
explanation. Function id is defined as a polymorphic function quantified on type u; it 
accepts a parameter, x, of type u and returns a value of type u, that value being x. 

Function foo is defined as a polymorphic, higher-order function, quantified on 
type s; it accepts as parameters a value, y, of type s, and a polymorphic function, bar, 
quantified on type t, which accepts and returns a value of type t. The function foo 
returns a value of type s, that value being the result of applying bar to y. 

Lastly, the variable oneTwoThree is declared and assigned the value resulting 
from applying foo, specialized to type int, to the value 123 and the function id. As 
this example demonstrates, for each specialization of foo, there must be a corresponding 
specialization of bar. 

Even in cases where the space complexity associated with textual polymorphism 
can be accepted, there are additional considerations. For example, the code generation 
scheme discussed above will not work when polymorphic procedures are first-class 
values [MDCB91]. | 

When functions are first-class, functions may be assigned and substituted for one 
another if of the same type. In the examples considered thus far, all functions were 
statically defined; that may not be the case for first-class functions. Consider Figure 14 
where a first-class polymorphic function, £00, is declared as one of two possible 


functions. If at run-time condition is true, the identifier foo is bound to the 
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polymorphic function, quantified on type t, which returns the first of it’s two actual 
parameters; otherwise it is bound to the polymorphic procedure which returns the second 
of it’s two parameters. The type specializations are known statically and the compiler 
can determine that function foo has to be specialized prior to call, but it cannot 


determine statically which of the two possible bindings to specialize. 


let foo = if <condition> then proc[t] (a, b: 
else proc[t] (a, b: 


let fooint FoolLine) (i, 2) 
let fooreal foof[real] (1.0, 2.0) 





Figure 14. Example of First-Class Polymorphic Procedure. 


One solution might be to generate specializations for both potential bindings and 
have the run-time system pass pointers the proper code. This solution, though, suffers 
from the same space complexity considerations discussed previously in the context of 
static specialization. 

Another solution might be to invoke the compiler dynamically whenever a new 
specialization is required. In other words, the function £00 would not be compiled at all 
until the proper binding has been determined. This solution could make the call to foo 
very slow and inefficient. 

In summary, textual polymorphic implementations demonstrate the ability to 
produce optimum code and data representations for each application of a polymorphic 
procedure and can be used to implement both ad hoc and uniform polymorphism. Major 
disadvantages, however, include a potentially large amount of generated code for each 


application of a polymorphic procedure and an inability to deal efficiently with first-class 


polymorphic procedures. 
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B. UNIFORM POLYMORPHISM 

If both the source code and the machine code for an implementation are 
independent of the data types being manipulated, and if the store representation is 
uniform for all data types, the polymorphic implementation is termed uniform 
polymorphism. ML uses this implementation technique. The function reverse of 
Figure 4 is written only once, compiled only once, and operates on any list, independent 
of the data type of it’s elements. 

The major trade-off for this form of implementation is that for uniform code to 
function correctly on all data types, the values for all data types must have a uniform 
representation (i.e., must all be of the same size). Using the list reversal function as an 
example, the underlying machine code must eventually swap around bytes in storage to 
perform it’s work; it must, as a minimum, know how many bytes to swap. If the code is 
to work uniformly on all data types (e.g., lists of integers, lists of reals, lists of strings, 
even lists of lists), all data types must be represented by the same number of bytes. 

This uniform representation may not be optimal for some types. For example, if a 
store size of one byte is used, it becomes difficult to implement double word floating 
point numbers. Ifa store size of eight bytes is selected, then the implementation of short 
integers and characters becomes inefficient. | 

A second complication arises in the implementation of compound data types. 
Because a fixed-sized data representation is required for uniform polymorphism and 
because compound data types can be arbitrarily large, pointers are the only efficient way 
to refer to them. The alternatives are clearly more inefficient or impossible: choosing a 
uniform representation large enough to hold any arbitrarily large data structure is 
impossible; choosing a representation large enough to hold the largest object in a system 
would be possible but would be extremely inefficient and, in the case of separate 
compilation, might be unknown. A third alternative, selecting a representation of some 
suitable arbitrary size and requiring all data objects to “fit” might also be possible but 


would add undesirable complications at the time of creation or reference. 
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If objects of compound data types are to be represented by pointers, and the 
representation is to be uniform for all data types, then all data objects must be represented 
by pointers. This adds a level of indirection to the implementation of every object in the 
system, including simple scalar objects such as integers. In an environment with implicit 
garbage collection, it also necessitates garbage collection on unused objects. 

Moreover, the overhead arising from uniform data representation will exist in the 
system even if polymorphic expression is not required in a particular module. The mere 
potential for such expression is sufficient to invoke the requirement. 

In summary, uniform polymorphism is relatively easy to implement and is 
relatively efficient with respect to space. However, all objects must be represented in a 


uniform, non-optimal form irrespective of the degree of polymorphism in the system. 


C. TAGGED POLYMORPHISM 

In some systems the source code and the machine code are both independent of 
the data type being manipulated but the data representations, and possibly the behavior of 
the program, are nonuniform for different data types. Such systems are instances of 
tagged polymorphism. In a tagged polymorphic implementation, each data item is tagged 
with some form of type information. The machine code is constructed to use this type 
information to determine dynamically which of several type-dependent instructions to 
execute. 

Examples of this form of polymorphism can be found in the implementation of 
inclusion polymorphism in many object-oriented languages. In the language Actor, for 
example, each object contains a method dictionary, with method names as keys and 
pointers to methods as values, which served as an address map for it’s methods. The 
static machine code for searching the method dictionary is the same for all methods in all 
objects but the dynamic behavior of the system depends on the value returned from the 
search. In this case, the method dictionary is effectively a tag. 

Tagged polymorphism, used in this fashion, can be seen as a means of 


implementing a built-in form of ad hoc polymorphism (overloading and coercion). The 
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common methods of a set of objects derived from a common super-class are, in a sense, 
simply overloaded functions. In the case where a method of the super-class is not 
redefined by a sub-class, the method of the super-class is invoked; in effect, the object of 
the sub-class is coerced to an object of the more general super-class. 

Another example, given in [MDCB91], is the tagged architecture of the 
Burrough’s B6500. That system included several polymorphic machine instructions, 
such as plus, minus, times, etc. Data was tagged according to it’s type and when an a 
plus operation, for example, was issued, the processor would inspect the tag and perform 
either integer or floating point addition, depending on the value of the tag. 

Tagged polymorphism can also be used to implement parametric polymorphism. 
However, it may be unacceptable to map an infinite number of types onto a finite number 
of tags. Still, to the extent that such a mapping is feasible for a given system, parametric 
polymorphic expression is possible. 

In summary, tagged polymorphism can implement ad hoc, inclusion and 
parametric polymorphism. It is efficient with respect to the amount of generated code 
and can operate with non-uniform data representations. However, the polymorphic 
expressions are built-in and, because all data objects must be tagged and those tags 


frequently inspected, the tagging system must be very efficient. 
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Hil. IMPLEMENTATION OF POLYMORPHISM IN NAPIER88 


This chapter presents a case study of the polymorphism implementation 
techniques used in Napier88. Chapter IV presents a case study of the polymorphism 
implementation techniques the recently proposed extensions to ML [Le92]. Both are 
functional languages with full polymorphic higher-order, first-class functions. While 
neither of the implementations studied here are directly transferable to Polymorphic C, 
many of the concepts and motivations behind these techniques are useful in developing 
an implementation strategy for Polymorphic C. 

Napier88 uses a variant of the tagged polymorphic implementation technique 
using procedure closures to capture type information. The primary thrust of the approach 
is based on the requirement that only polymorphic procedures should pay the penalty for 
polymorphic expression and the observation that only the polymorphic expressions 
within polymorphic procedures need exhibit uniformity of behavior. Outside a 
polymorphic procedure, this uniformity is not necessary. 

All data objects are stored in their system-dependent, optimal representations 
(called concrete form) and can be manipulated by monomorphic procedures in that 
concrete form. Objects which are passed to quantified formal parameters of a 
polymorphic procedure are coerced to a uniform representation (e.g., pointers) on 
entering the polymorphic procedure and coerced back to their concrete representation on 
exit from the procedure. Within the polymorphic procedure, the objects are manipulated 
using their uniform representation. 

The following discussion closely follows [MDCB91] which contains a complete 


description of the implementation of polymorphism in Napier88. 
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A. POINTS OF CONVERSION 

As stated previously, objects with concrete representation must be coerced to 
uniform representation if passed to the quantified formal parameter of a polymorphic 
procedure. This coercion might be performed either before or after the call. 

For a programming language that allows the combination of first-class procedures 
and type specialization without call, the compiler is unable to determine statically 
whether a procedure being called is polymorphic or monomorphic. This is the case in 


Napier88. Consider the Napier88 code in Figure 15. 


LOC First = procit| ta, De Eb => Ly 7- a 


let either = if <condition> 
then first[int] 
else proc(a, b: int -> int); b 


let two = either(2,3) 





Figure 15. First-Class Procedure and Specialization Without Call. From [MDCB91]. 


In this code, the procedure first is a polymorphic procedure which returns the 
first of two quantified parameters. At the time of the call either (2,3), if 
condition is true the identifier either is bound to the first-class polymorphic 
procedure first, specialized for type integer, which returns the first of two integer 
parameters. Otherwise, it is bound to a monomorphic procedure of type int -> int 
which returns the second of two integer parameters. 

In either case, the compiler does not know statically whether the procedure being 
called is polymorphic or monomorphic and therefore cannot determine statically the 
proper representation (uniform or concrete) for the actual parameters. If a conversion is 
performed and the function turns out to be monomorphic, therefore expecting concrete 


actual parameters, the results are unpredictable. This problem could be solved by 
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compiling monomorphic functions to accept uniform values and convert them as 
required, but that solution violates the requirement that only polymorphic functions suffer 
polymorphic overhead. 

As aresult, the conversion to uniform representation must be delayed until after 
the call. If the procedure turns out to be polymorphic, the conversion would have to 
occur within the polymorphic procedure itself. 

In general, there are four cases of interest when passing parameters to a 
polymorphic procedure. These are shown in Table 2 and discussed in the following 


sections. 


Table 2. Passing Parameters to Polymorphic Functions. 










l. Concrete Actual Parameter Passed to Concrete Formal Parameter 
This case is trivial since there is no polymorphism involved. The compiler is free 


to generate monomorphic code. 


2. Concrete Actual Parameter Passed to Quantified Formal Parameter 

In this case, for every formal parameter of a quantified type, the concrete actual 
parameter must be converted inside the polymorphic procedure to the system’s uniform 
representation and the result - if of a quantified type - must be converted back to it’s non- 
uniform representation on exit. Figure 16 shows an example. 

On the calls first{[int](1, 2) and second[int] (1, 2), the first 
formal parameter x is of quantified type, so the first actual parameter, 1, is converted to 


the system’s uniform representation. The second formal parameter y, however, is of 
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Liarslt. = proc(t) (x2 3 
second = proc[t] (x: t; 


one = first[int] (1, 2) 
two = second[int] (1, 2) 





Figure 16. Concrete Actual Parameter Passed to Quantified Formal Parameter. 


concrete type, so the second actual parameter, 2, is left in it’s optimum, concrete 
representation. In this regard, the two calls are identical; the first actual parameter is 
manipulated in the system’s uniform representation while the second actual parameter is 
manipulated using it’s concrete representation. 

On exit, however, the two procedures behave differently. In the case of the call 
first[int] (1, 2), the return value, 1, is of quantified type and must be converted 
back to it’s original representation. In the call second[int] (1, 2), the return value, 
2, is of concrete type and, so, need not be converted. 

In all instances of this case, specialized code is required to convert from any 
representation to/from the uniform representation. All other code in the polymorphic 


procedure is uniform. 


3. Quantified Actual Parameter Passed to Concrete Formal Parameter 

As seen above, a polymorphic procedure converts objects passed via quantified 
formal parameters to a uniform representation. If the polymorphic procedure 
subsequently passes that object to another procedure(be it monomorphic or polymorphic) 
via a concrete formal parameter, the object must be converted to it’s concrete 
representation prior to the call. Figure 17 shows an example. 
| Here, procedure foo is quantified on type t and takes as quantified parameters x, 
of type t, and y, a procedure of type t -> t. Since both parameters are quantified, 
both are converted to uniform representation on the call to foo. The procedure returns a 


quantified value which is obtained by applying the second parameter to the first. 
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let int_id = proc(x: int -> int); x 


Let, foo = procit| (xs Le ye proctt.=> £) => t)7 ys) 


let three = foo[int] (3, int id) 





Figure 17. Quantified Actual Parameter Passed to Concrete Formal Parameter. 


In this case, however, the second parameter is the monomorphic integer identity 
function which expects to be passed an integer in concrete form. Therefore, the actual 
parameter must be converted to concrete form prior to the call and the return value must 
be reconverted to uniform form after the return. Prior to returning from foo, the result is 


again converted to concrete form. 


4. Quantified Actual Parameter Passed to Quantified Formal! Parameter 

Polymorphic procedures expect to convert their parameters to uniform 
representation on entry. This means that a polymorphic procedure which passes an object 
with uniform representation to a procedure via a quantified parameter must pass that | 
object in it’s concrete representation. The behavior is the same as given in the third case; 
the object must be converted to concrete form prior to the call and reconverted following 


return. Figure 18 illustrates this case. 


Here, the polymorphic procedure id2 is the polymorphic identity function, 
quantified on type t. It’s return value is obtained by invoking procedure id1, another 
version of the polymorphic identity function. At the time of the call, id2 is initialized at 
type int and, so, idl is also initialized at type int. Asa result, idl expects a 
parameter of type int and, being a polymorphic procedure, it expects convert that 
integer to uniform representation. It is necessary, then, for id2 to convert the actual 


parameter y to the concrete representation for integers prior to the call to id1. 
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let idl proc[s] (x: s -> Ss); x 
let id2 proc(cl(ys ©. HSE) s 2a Pecy) 


let two 5 ae Us is 6 a I eae 





Figure 18. Quantified Actual Parameter Passed to Quantified Formal Parameter. 


B. DATA STRUCTURES 

The preceding discussion on points of conversion dealt solely with atomic types. 
The introduction of data structures raises one minor additional issue, best illustrated by an 
example, shown in Figure 19. 

Here, the data structure tuple is defined and is given a constructor called 
make tuple. Both are quantified with respect to their formal parameters. The call 
make tuple[int, int] (1,2) leads to the creation of the ordered pair (1, 2). 

This single data structure might be referenced after creation by both monomorphic 
and polymorphic procedures. If referenced by a polymorphic procedure, the individual 
fields of the tuple must be referenced using a uniform representation. If referenced by a 
monomorphic procedure, it’s fields must be referenced using the system’s concrete 
representation. 

The solution to this problem is to view access to compound data structures as a 
special case of parameter passing. They are always created and stored using concrete 
representation to allow access by monomorphic procedures. When they are accessed by a 


polymorphic procedure a conversion takes place within the polymorphic procedure. 


Cc. NAPIER88 BLOCK RETENTION ARCHITECTURE 

If a language does not incorporate block retention, the memory reserved for 
variable declared within a block may be reclaimed on exit from the block. Languages 
that support arbitrary higher-order functions, as does Napier88, must incorporate a block 


retention architecture, meaning that variables declared within a block may persist after 
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type tuple[s, t] is structure (first: s; second: t) 


let make tuple = proc[u, v] (a:u; b:v -> tuplel[u, v]) 
tuple[u, v] (a, b) 


let this tuple = make tuple[int, int] (1, 2) 





Figure 19, Creation of Data Structure by Polymorphic Procedure. 


exit from the block. An example might be the internal static variable found in C. The 
example of Figure 20 illustrates this. 

The block defined by random contains the declaration of the variable seed. If 
random is to work correctly, seed must persist between calls to random. If it does not, 
random will return the same value each time it is called. As will be seen later, internal 
static variables such a seed are important to the Napier88 implementation of 
polymorphism. 

It is also worth noting that Polymorphic C does not support internal static 
variables. Such variables would have to be declared as uniquely-named global variables. 
Being global, their lifetime is that of the program, so the requirement for block retention 


does not apply to Polymorphic C. 


let random = 

begin 
let seed := 2111 
proc {=> int) 


begin 
seed := (519 * seed) div 8192 
seed 


end 
end 





Figure 20. Block Retention. From [MDCB91]. 





D. IMPLEMENTATION OF ATOMIC TYPES 

Earlier discussions with respect to points of conversion made clear that under the 
constraint imposed by the Napier88 implementors (only polymorphic procedures pay a 
penalty for polymorphism), polymorphic functions were required to convert their formal 
parameters to and from concrete and uniform representations. But how is this 
accomplished? 

Clearly, if a polymorphic procedure is to convert a data object from uniform to 
concrete form prior to return, it must know the concrete form to which it should be 
converted. This functionality cannot be hard-coded in the polymorphic procedure (e.g., 
always convert to concrete representation for integers) because the function 1s 


polymorphic and must work with values of any type. 


The tagged implementation discussed in Chapter II might be used for the 
conversion but data tagging is contrary to the requirement that only polymorphic 
functions suffer overhead due to polymorphism; if all data is tagged to support 
polymorphism, then the entire system, including the monomorphic part, suffers the 
overhead associated with polymorphism. 

The only other solution is for the polymorphic procedure to receive, in some 
manner, information about the concrete types of it’s quantified parameters. One possible 
solution might be to simply pass type information to the function as a separate parameter. 
This will work, but the implementors of Napier88 chose an alternative solution which 
takes advantage of block retention in the language (i.e., internal static variables). This 
helps avoid having to pass an extra parameter at each function application. 

In Napier88, a polymorphic procedure is compiled into one in which the type 
parameter is represented by an integer in an outer level (envelope) procedure of the same 
name. The polymorphic executable code is bound to the envelope procedure, with the | 


result that the type tag is contained in its closure. For example, consider the arbitrary 
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polymorphic function foo as defined and applied in Figure 21(a), which would be 
compiled into that shown in Figure 21(b). 


(a) let foo = proc[t] (x: t -> t); 


let a = foo[int] (3); 


(b) let foo = proc(tTag:int -> proc(a@ -> q@)) 
proc (Xia =—> a); 





Figure 21. Napier88 Polymorphic Identity Function. After [MDCB91]. 


In Figure 21(b), t Tag is an integer encoding of the quantifier’s specialization 
type; it varies for each call. For example, a particular system might have a mapping 
represented by the following case statement for the concrete type t: 


let tTag = case 7 of: 


T= int al 
T= string :2; 
t= real 3; 
default 0:3 


The symbol o represents, at any type specialization, the concrete type of the quantified 
type [MDCB91]; in other words, it is a type variable. 

For clarification, consider the call foo [int] (3) of Figure 21(a), which is 
compiled into two calls. The first is equivalent to let int foo = foo[int]. This 
creates an envelope procedure of type proc (tTag:int -> proc(a -> a) ) with 
the type tag for type int; the result is a monomorphic procedure called int foo. In 
this case, int foo is monomorphic code which, for this specialization, happens to have 
the type tag for int contained in an internal static variable. The original polymorphic 
code for foo is dynamically bound to this envelope procedure; thus it has the type tag 


for int in its closure. 
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The second call is equivalent to int foo (3), which calls the polymorphic 
executable code with the concrete parameter 3. After the call to the polymorphic 
procedure, the concrete parameter must be converted to the uniform data representation. 
To do this, a special built-in generic instruction, called convertToPoly(t Tag), inserted 
into the body of foo at compile time, is invoked. This instruction uses the type tag 
contained in the closure of the polymorphic code to convert the concrete parameter to the 
system’s uniform representation. Prior to exit from the polymorphic code, the built-in 
generic instruction convertFromPoly(t Tag) is executed, again using the type tag in the 
code’s closure to perform the proper conversion. In this way, the polymorphic code can 
remain uniform for each specialization yet perform conversions to and from concrete 
representations of any type. 

Thus, the call foo [int] (3) would result in the following chain of events. An 
envelope procedure, call it int foo, would be created and the integer encoding for type 
int would be placed in a variable, tTag, local to int foo. The polymorphic code 
id would then be bound to int _ foo, causing tTag to be visible to foo, or, more 
specifically, to elements within the body of foo. Procedure foo is then called with the 
integer value 3. 

Within the body of id, the integer must be converted to uniform representation. 
The first statement in foo is an invocation of the generic system instruction 
convertToPoly(tTag) (3), the result of which is the integer 1 represented in 
uniform form; assume it is bound to identifier x. The polymorphic procedure is then free 
to manipulate x in a uniform manner. Prior to exiting the body of foo, the return value 
must be converted back to concrete representation by invoking the generic instruction 
convertFromPoly(tTag) (x). The result of that call is returned. 

If £00 is subsequently called with a value of a different type, a new envelope 
procedure with a different type tag is created and the polymorphic code for foo is 
dynamically re-bound to this new procedure. Thus, from the standpoint of the 


polymorphic procedure foo, the only difference between the call id[real] (3.0) 
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and the call id[int] (3) is the value of tTag in its current closure. The code for id 
remains the same; in fact, the exact same machine code is executed in each case. The 
only difference lies in which type-specific versions of convertToPoly (tTag) and 


convertFromPoly (tTag) are invoked at entry and exit. 


E. IMPLEMENTATION OF DATA STRUCTURES 

As mentioned previously, all data structures are stored in non-polymorphic form; 
when the fields of a data structure are accessed by a polymorphic procedure, they are 
converted for use within the procedure and are reconverted when returned to the data 
structure. This scheme is necessary to allow monomorphic procedures to access the 
structures normally. 

There are two cases where a polymorphic procedure may manipulate a value of a 
quantifier type that is part of a data structure: (1) when the data structure is passed as a 


parameter and (2) when the data structure is created within the procedure and returned as 


its value. 


1. Data Structure Passed as Parameter 

Figure 22 shows an example of passing a structure with quantified fields to a 
polymorphic procedure. The procedure findSi ze is defined as a procedure, quantified 
on types s and t, which takes as a parameter a structure, A, with two fields: age, of type 
s and size, of type t. The procedure returns a value of type t, that value being the 


value in the size field of the structure. 


let findSize = proc{[s, t] (A:structure(age:s; size:t) -> t) 


A(size) 





Figure 22. Passing Structures with Quantified Fields. From [MDCB91]. 
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Clearly, since the size of the concrete representations of the types s and t are 
unknown and potentially variable, it would be impossible to compile findSize using a 
constant offset for the field size. That information would have to be calculated at run- 
time and passed to the polymorphic procedure. 

As in the case of passing type information to a polymorphic procedure, there are 
two solutions. The first solution, passing offset information as additional parameters, was 
excluded from consideration in favor of simply extending the tagging method described 
previously for atomic types. In addition to a type tag for each quantified formal 
parameter, a field offset value for each field in each quantified formal parameter taking a 
compound data type is passed to an envelope procedure. These values are then available 
to the embedded polymorphic procedure in its closure. Figure 23 shows the compilation 


of the findSize procedure. 


let findSize = proc(sTag, tTag, ageOffset, sizeOffset:int 
-> proc(A:structure(age:a, size:B) -> B)) 


proc(A:structure(age:a, size:B) -> B) 
A(sizeOffset) 





Figure 23. Compilation of Figure 22. From [MDCB91]. 


Some clarification of the syntax is required. The procedure findSize is 
compiled as a monomorphic procedure which takes as parameters four integers; the first 
two are the usual type tags representing the concrete types of the fields, the second two 
are the offsets of those fields. The polymorphic code representing the original findSize 
procedure is bound to this envelope procedure. It takes as parameters a value for age 
and a value for size, both of quantified type, with the type tags and offsets for those 


fields contained in its closure. Upon call, that polymorphic procedure uses the 
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information in its closure to convert it’s actual parameters to and from uniform form and 


to index into the structure. 


Ze Data Structure Created Within Polymorphic Procedure 

A second addressing problem occurs when a data structure is created within a 
polymorphic procedure. The structure must be created in concrete form for non- 
polymorphic use, however neither the offsets for the fields nor the overall size of the 
structure are known at compile-time; they depend on the particular specialization of the 
call. 

Once again, offset information might either be passed to the polymorphic function 
in the form of additional parameters or it may be left in the closure of the embedded 
polymorphic function in the form of local declarations within it’s envelope procedure. If, 
however, the structure is totally encapsulated by the polymorphic procedure, no offset 
information would be available at the time of call. 

The Napier88 solution is to generate code within the envelope procedure to 
calculate this information and to leave it in the closure of the polymorphic procedure in 
the form of local declarations. This code uses another built-in system procedure, the 
monomorphic procedure t ypeSi ze, to do this work. Figure 24 shows a polymorphic 
procedure, mkPair, and its compilation using this scheme. 

Again, the Napier88 syntax is in need of clarification. The procedure mk Pair is 
defined as a polymorphic procedure, quantified on types s and t, which takes as 
parameters first, of type s, and second, of type t. It returns a structure with fields 
fst and snd of types s and t respectively. The structure is the result of assigning 
first to fst and second to snd. 

As compiled, mkPair is defined as a monomorphic function with two integer 
parameters as type tags. The polymorphic code representing the original mk Pair is 


bound to this envelope procedure as usual. 
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let mkPair = proc[s, t] (first:s; second:t 
-> structure(fst: s, snd: t)) 
struct (fst=first, snd=second) 


let mkPair = proc(sTag, tTag:int 
-> proc(a, B -> structure(fst: a; snd: fB))) 


begin 
let fstOffset = 0 
let sndOffset = fstOffset + typeSize(sTag) 
let structSize = sndOffset + typeSize(tTag) 


proc(first: a; second: B -> structure(fst: a; snd: B)) 
struct (fstOffset=first, sndOffset=second) 
end 





Figure 24. Compilation of Polymorphic Procedure mkPair. [From MDCB91]. 


In the body of the envelope procedure (following the begin statement), the 
offsets and overall size for the structure are calculated using the built-in typeSize 
procedure and the type. Finally, the polymorphic procedure is called and uses the offsets 
contained in its closure to assign the concrete values, first and second, to the 


appropriate addresses within the structure. 


F. EFFICIENCY AND OPTIMIZATION 

The main advantage to the Napier88 technique is that only values of quantifier 
type are tagged. There is no overhead for monomorphic procedures and there is no 
overhead for monomorphic portions of polymorphic procedures. 

There are two sources of run time overhead. The first is in the fact that two 
procedure calls are made for every call to a polymorphic procedure: one to the envelope 
procedure and one to the polymorphic code. The second is in the calls to the built-in 
procedures which convert between forms and calculate type size information. 

[MDCB91] mentions several possible optimizations which are discussed here 


briefly. 
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ie Specialization Through Partial Application 

If polymorphic procedures are specialized once then called many times, the cost 
of creating envelope procedures can be amortized over many calls. For example, if the 
polymorphic identity function is to be called repeatedly with values of type integer, it 
would be wise to specialize it once (e.g., let int id = id[int]) and then call 
int id. This is equivalent to the textual polymorphic approach, except specialization is 


performed at run time vice compile time. 


2. Generate Inline Code 
It might be possible, from static inspection of the code within a compilation unit, 
to generate inline code instead of making polymorphic procedure calls. There is no need, 


for example, to make the call let x = id[int] (123). 


3: Use Textual Polymorphism 

In the case where very few specializations are required, it may be more efficient to 
generate pure monomorphic code for each type of interest than to suffer the overhead 
associated with polymorphism. This approach will not be efficient if the number of 
specializations and/or the number of quantified parameters is large. It will not work at all 


in the case of first-class polymorphic functions. 


4. Static Analysis 

It may be possible to elide unnecessary conversions. For example, if a 
polymorphic function is declared within another polymorphic function and can never 
escape the scope of that function, it can be compiled to accept parameters passed in 


uniform form. This would elide four unnecessary conversions to/from concrete form. 
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IV. IMPLEMENTATION OF POLYMORPHISM IN ML 


A second strategy for the implementation of polymorphism is that used in 
implementing ML [Le92]. Historically, most implementations of ML have used a 
uniform data representation, specifically single-word pointers, for all data objects in order 
to support polymorphic functions. A primary result of [Le92] was to allow for a mixed 
data representation in ML, thereby improving efficiency. This work has been extended in 
[ShA95] and [Th95]. 

The implementation strategy in this chapter is similar in many respects to that of 
Napier88. On a surface level, it is just a variation on the same theme. Values are stored 
in concrete form, making monomorphic functions much more efficient in the presence of 
optimal data representations. Values passed to polymorphic functions via quantified 
formal parameters must share a common representation; concrete actual parameters must 
therefore be converted to uniform form. 

However, ML differs from Napier88 in several important ways, one of which is 
critical to the implementation of polymorphism. While Napier88 supports type 
specialization at run-time, ML does not. This seemingly minor difference allows an ML 
program to be fully type checked statically which allows much greater freedom in the 
choice of implementation strategies. Polymorphic C also has these properties. 

This chapter is structured very much like the previous chapter. After introducing 
a few terms, we review the possible points at which conversions to and from uniform 
representation might be required. We then discuss implementation details for atomic data 
and compound data structures. The chapter concludes with a discussion of efficiency and 


optimization issues. 
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A. BOXED AND UNBOXED VALUES 

The proposed implementation technique uses some form of uniform 
representation of data for use by polymorphic functions. In the discussion of Napier88, 
we used the terms concrete and uniform form. While those terms are generic and are still 
applicable, the literature regarding polymorphism in ML introduces some other related 
terms. 

The bit-pattern representing a value on which machine instructions operate is 
called an unboxed value; 32-bit integers, 64-bit long integers, single- and double- 
precision floating point numbers, etc., are all examples of unboxed values. A pointer to a 
heap-allocated box containing an unboxed value is called a boxed value. [PJ91]. 

Conversions to and from concrete form are performed by a pair of generic 
operators called wrap (t) and unwrap (tT), where t is some concrete type. Wrap (T) 
performs the conversion from the concrete representation of type t to the uniform 
representation and is usually implemented by boxing the object. The result of this 
operation is a data object which is said to be in the wrapped state or, simply, wrapped. 
Unwrap (t) performs the conversion from uniform representation to the concrete 
representation of type t, by performing the converse of the wrapping operation on that 
type; the result is an unwrapped object. 

At times when context is not important, the terms uniform, boxed and wrapped, 
and the terms concrete, unboxed, and unwrapped, are roughly synonymous. There are 
subtle differences, though. In the implementation of ML, wrapping is most often 
performed by boxing to obtain a uniform representation; unwrapping is generally 
performed by unboxing to obtain a concrete representation. 

For clarity in the examples given in following sections, when there is only one 
concrete type involved we will drop the type quantifier and use the simpler terms wrap 


and unwrap vice wrap(t) and unwrap(t). 
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B. POINTS OF CONVERSION 

In the discussion regarding Napier88 we showed that for a language which allows 
both first-class functions and type specialization without call it is impossible to know 
statically whether or not a procedure being called is polymorphic. Because of this, values 
being passed via quantified formal parameters could not be converted to uniform 
representation before the call. 

However, ML does not allow partial application of types. All variables are 
statically bound and their type is known at compile-time. By way of explanation, 
consider the ML code of Figure 25 (an expansion of the Napier88 code shown earlier in 


Figure 15. 


Frrst (x,y) = -xF 
second (x; yi1nt) = -y; 
condition = true; 


either = if condition then first else second; 
two = e1ther(7, .s)s 

condition = false; 

three = either(2, 3); 





Figure 25. Effect of Static Binding in ML. 


The polymorphic function first is defined as one which takes two quantified 
parameters, x and y, and returns x; it is assigned the type a * B —> a. Then the 
monomorphic function second is defined as one which takes two integers, x and y, and 
returns y; itis assigned typeint * int -> int. 

Identifier either is bound to either the function first or the function 
second, depending on the truth value of condition. In this example, condition 
has been assigned the truth value t rue, so either is statically bound to first. Asa 


result, on the call val two=either(2, 3) the value 2 is returned. 
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This binding for either is static, depending only on the environment at time of 
definition. If condition is given a new binding as shown in Figure 29 and either is 
called a second time, the return value will not change; the function either is still 
bound to first. 

Because of static binding, the type inferencing engine is always able to determine 
the type of a function at compile time. The function may be monomorphic or 
polymorphic but, unlike in dynamically-bound languages such as Napier88, there is no 
ambiguity and, especially, there is no ambiguity at run time. As a result, the requirement 
to convert values from concrete to uniform form before, vice after, the call to a 
polymorphic, higher-order function does not apply. We are free to adopt either 
conversion convention. 

In fact, [Le92] has adopted the convention that conversions should occur before 
the call to a polymorphic function. In light of this difference, it is useful to once again 
consider the high-level issues surrounding the various points of conversion. Recall that 
there are four cases of interest when passing parameters to a polymorphic procedure. 


These are shown in Table 3 and discussed in the following sections. 





Concrete actual parameter passed to concrete formal parameter. 
Concrete actual parameter passed to quantified formal parameter. 







Quantified actual parameter passed to concrete formal parameter 
Quantified actual parameter passed to quantified formal parameter. 


Table 3. Passing Parameters to Polymorphic Functions. 


1. Concrete Actual Parameter Passed to Concrete Formal Parameter 
As before, this case is trivial since there is no polymorphism involved. The 


compiler is free to generate monomorphic code. 
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2. Concrete Actual Parameter Passed to Quantified Formal Parameter 
In this case, every concrete actual parameter being passed to a function via a 
quantified formal parameter must be converted to uniform representation prior to the call 


and the result, if of quantified type, must be converted back to concrete form after the 


return. 


3. Quantified Actual Parameter Passed to Concrete Formal Parameter 

If a polymorphic procedure receives a value in uniform form and subsequently 
passes that value to another procedure via a concrete formal parameter, the value must be 
reconverted to its concrete form before the call. In the absence of some sort of trick (e.g., 
tagging), it is not possible for the conversion to occur before the call; doing so would 
subvert the polymorphic nature of the calling function. Figure 26 shows an example with 


unnecessary details omitted. 


polySort(aList, aComparisonFunction) = 


intCompare(x,y: int) = 
MCLs S 352,24 ;-L12 


aSortedintList = polySort(intList, intCompare) ; 





Figure 26. Passing Quantified Actual Parameter to Concrete Formal Parameter. 


First, a polymorphic sort routine, pol ySort, is declared; it takes as parameters 
a list of quantified type and a comparison function operating on elements of the list. 
Then, a monomorphic integer comparison function, int Compare, and an integer list, 
intList, are declared and passed as parameters to polySort. Because polySort is 
polymorphic and it’s parameters quantified, int List is converted to uniform 


representation prior to the call. 








The function polySort will, in the course of its work, determine whether to 
swap two list elements by applying the comparison function to two of those elements. 
The comparison function is monomorphic and, so, expects to receive it’s parameters in 
concrete form. But polySort received them in uniform form. An explicit conversion 
in the body of polySort, in this case to type integer, would effectively cause 
polySort to become monomorphic. 

There are two common solutions. The first is to incorporate a tagging 
mechanism, whether that tag is actually embedded in the data type or passed as an 
additional parameter to the polymorphic procedure. In this case, polySort could 
inspect the tag, invoke the appropriate conversion utility and pass the parameter. 

A second solution, and the one chosen in [Le92], is to build a monomorphic 
envelope procedure that performs the correct conversions and then invokes the called 
monomorphic function. The polymorphic calling function is free, then, to call the 
envelope procedure, passing values in uniform form, and to rely on the envelope 
procedure to perform the proper conversions. Numerous examples are given in following 


sections. 


4. Quantified Actual Parameter Passed to Quantified Formal Parameter 

If a polymorphic procedure receives a value in uniform form and subsequently 
passes that value to a polymorphic procedure via a quantified formal parameter, no 
conversion is required. The called procedure expects a value in uniform form and will 
receive it as such. Likewise, no conversion is required on return from the called 


procedure. 


C. IMPLEMENTATION OF ATOMIC TYPES 

In the approach introduced in [Le92], the implementation of polymorphism for 
atomic types is straightforward. Between calls, atomic objects are stored in concrete 
form. Monomorphic functions are compiled using optimal, system-dependent data 


representations. Polymorphic functions are compiled using uniform data representations. 
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Conversions between forms are required in only three instances: before passing a 
concrete value to a polymorphic function via a quantified formal parameter, after return 
from a polymorphic procedure if the return value is of quantified type, and when passing 
a quantified value to a function via a concrete formal parameter. These cases are 
addressed in turn in the following sub-sections. 

The program transformations used to realize these conversions are extremely 
elegant and powerful. Some final results are given below. A more comprehensive 
treatment of the transformation, along with the derivations of the examples in this 


chapter, is provided in the Appendix. 


1. Applying Polymorphic Functions to Concrete Values. 

As stated in the previous section, when passing a concrete value to a polymorphic 
procedure via a quantified formal parameter, conversions to and from concrete form 
occur prior to the call and the results, if of quantified type, are reconverted following 


return. Figure 27 demonstrates this technique. 


(unwrap (id(wrap(1))); 





Figure 27. Applying a Polymorphic Function to a Concrete Value. 


In Figure 27, a polymorphic identity function, id, is defined. The subsequent 
application of id to the concrete parameter, 1, of type int, is transformed to the code 
shown on line (a). Here, the integer 1 is wrapped, id is applied to the wrapped integer, 


and the result of evaluating the expression is unwrapped and bound to identifier one. 
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A slightly more interesting example is shown in Figure 28. Here, the 
polymorphic function first is defined as one which returns the value found by 


applying the polymorphic identity function, id, to the first of it’s parameters. 


first(x,y) = id(x); 


a firsti(i, 2.0)% 


a unwrap (int) (first (wrap(int) (1),wrap(real) (2.0)); 





Figure 28. Second Example of Polymorphic Function Application in ML. 


The application of first to the values 1 and 2 . 0, the first of type int and the 
second of type real, would be compiled as shown on line (a). The two arguments are 
wrapped using the appropriate instantiation of the wrap operator and the function 
first is applied to these wrapped values. Function first, in its body, is free to pass 
the wrapped integer to id which, being polymorphic, expects wrapped values itself. 
Since the result of first is of quantified type, it is unwrapped after the return and 


bound to identifier a. 


2. Passing a Wrapped Value via a Concrete Formal Parameter. 

The remaining instance where conversion between forms is required is when a 
wrapped object is passed via a concrete formal parameter. As stated earlier, in this case 
an envelope function is created to perform the proper conversion and apply the 
monomorphic function to the converted values. The examples of Figures 29 and 30 help 
clarify the method. 
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fun Succ(xtint) = x +1; 


fun apply(f,x) = £(x); 


val two = apply(succ, 1); 





Figure 29. Passing Quantified Actual Parameter via Concrete Formal Parameter. 


The problem is set up in Figure 29. Two functions are defined. The first, succ, 
is the monomorphic integer successor function of type int -> int; it takes an 
unwrapped integer as its only parameter. The second function, apply, is a polymorphic, 
higher-order function of type (a —> B) * a —> B that applies it’s first parameter, a 
function of type « —> B, to its second parameter, a value of type a, resulting in a value of 
type B. The function apply is then applied to succ and the integer 1, and the result is 
bound to identifier two. 

Since apply’s second formal parameter, x, is quantified, the second actual 
parameter (the integer 1) must be wrapped prior to the call. But this causes difficulties. 
The function succ is monomorphic and takes an unwrapped integer as its parameter; it 
will not work correctly if it is passed a wrapped integer. For example, if wrapping is 
performed by boxing the integer, the result is a pointer. The result of applying succ toa 
pointer would be to increment the pointer, causing it to point to whatever was in the next 
higher word in storage, vice incrementing the integer to which the pointer pointed. 

There are several ways to solve this problem (e.g., tagging, passing extra 
parameters). The method chosen in [Le92] is the use of a program translation to generate 
an envelope function around the monomorphic function. For the example of Figure 29, 
the envelope function for succ would be as shown in Figure 30(a), with the application 


of apply translated as shown in Figure 30(b). 
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(a) Xx.wrap (Succ (unwrap (x) ) ) 


(b) val two = 
unwrap (apply (Ax.wrap(succ(unwrap(x)))), wrap(1)); 





Figure 30. Result of Translating Figure 29. 


The envelope function of Figure 30(a) is simply a function abstraction which 
takes a parameter x, unwraps it, applies the monomorphic function succ to the 
unwrapped value, and then wraps the return value. 

Figure 30(b) demonstrates the overall translation caused by the application of 
Figure 29. The envelope function is generated as a local function abstraction and the 
second actual parameter, the integer 1, is wrapped. The function apply is then applied 
to these two objects. In the body of app1y, the envelope function is applied to the 
wrapped integer. In the body of the envelope function, the integer is unwrapped and the 
function succ is applied to the unwrapped integer. In the body of succ, the integer is 
incremented and the result is returned to the envelope function. The envelope function 
wraps the integer and returns the wrapped integer to the function apply. The function 
apply returns the wrapped integer to the original calling routine where it is unwrapped a 
final time and bound to the identifier two. 

It is useful, in the context of wrapping and unwrapping of actual parameters to 
view Ax.wrap (succ (unwrap (x) )) as the “wrapped” version of succ. If the 
wrapped version is given a name, succ’, the translation given in Figure 30 could be 


expressed more succinctly, as shown in Figure 31. 


(a) succ’ = Ax.wrap(succ (unwrap (x) )) 


(b) val two = unwrap(apply(succ’, wrap(1)); 





Figure 31. Different View of Figure 30. 
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D. IMPLEMENTATION OF DATA STRUCTURES 

So far, we have considered only the implementation of atomic data types. The 
extension of this scheme to composite data types is straight forward. The following 
discussion is divided into two parts covering, first, simple composite types (e.g., tuples 


and records) and, second, the more complex case of recursive data types (e.g., lists). 


1. Simple Composite Data Types 

Simple composite data types include tuples and records. They are of a fixed, 
known size and are not recursive. Because of this, their implementation is a simple and 
direct extension to the implementation already discussed for atomic types. 

Passing a record, for example, to a polymorphic function is simply a matter of 
wrapping each field in the record prior to the call and unwrapping everything after the 
call. In the case where one of these simple structures is created by the polymorphic 
function vice being passed to it, the scheme is even simpler: the polymorphic function 
creates the structure in wrapped form and it is unwrapped upon return. Figure 32 gives 
an example of this latter case. 

In this example, the polymorphic function mkPair is defined as one which takes 
a parameter of quantified type and returns a pair. The call mkPair (3.14), for 
example, would result in the creation of the pair (3.14, 3.14). Figure 32(a) shows 
the translation of the call. This translation could be rewritten as shown in Figure 32(b), a 
notation which might be more comfortable to an imperative language programmer. 

Prior to calling mkPair, the actual parameter is wrapped. On return, the first and 
second elements of the tuple are extracted, using the built-in fst and snd operators, and 
are unwrapped prior to being bound to the identifier real Pair. 

The clear implication so far is that these simple structures are stored in concrete 
form. This is often the case but, if the size of the structure is large, wrapping and 


unwrapping each field can be expensive. In some cases, it might be better to store these 
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mkPair (x) 


realPair makePair(3.14); 


realPair let x = mkPair(wrap(3.14)) 
in (unwrap(fst(x)), unwrap(snd(x))); 


realPair (unwrap (fst (mkPair(wrap(3.14))), 
unwrap (snd(mkPair(wrap(3.14)))); 





Figure 32. Creation of Data Structure in Polymorphic Function. From [Le92]. 


structures in a wrapped representation at all times. Figure 33 shows three possibilities, 
using boxed values as the uniform (wrapped) representation. 

Figure 33(a) shows the standard boxed representation used by most current ML 
implementations. Every field of every record is boxed before being assigned to the 
record. Here, the record x is represented as a pointer to a set of four boxed values, two of 
which are reals and two of which are strings. Likewise, record y is a record represented 
as a pointer to three boxed values, all reals. Access to any of these fields requires 
unboxing, an inefficient exercise for such routine computations as arithmetic. 

A more efficient data representation is seen in Figure 33(b). Here, the real 
numbers are stored in their unboxed form, while the strings remain boxed, as is typical of 
most languages. Mixing data types in the manner of record x, however, complicates the 
object descriptor used by the garbage collector. 

A better solution is to re-order the fields of the record so that all unboxed fields 
are ahead of all boxed fields. The object descriptor then consists of two short integers: 
one indicating the length of the unboxed part, the other the length of the boxed part. 
[ShA95]. Figure 33(c) gives an example of this representation. 
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(4.51, “hello”, 3.14, “world”); 
(4.51, 3.14, 2.87); 


(a) Standard Boxed Representation 


(b) Flat Unboxed Representation 


(c) Flat Representation with Reordering Fields 





Figure 33. Data Representations for Records. From [ShA95]. 


This third method is used by both [Le92] and [ShA95], making access to record 
fields very efficient for monomorphic code. Of course, any unboxed fields will have to 


be boxed prior to being passed to polymorphic code via quantified formal parameters. 
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2. Recursive Data Types 
Recursive data types are those whose values are composed from values of the 
same type [Wa90]. One common example suitable for this discussion is the list type in 


ML, defined as follows: 
datatype a list = nil | cons of a*aqa 1ist; 


In other words, a list is either an empty list or it is a value of type a followed by a list of 
typea list. Any list, then, is built up recursively from the empty list, nil; the list 
[1,2,3] could be written as cons (1, cons (2,cons(3,nil))). 

Like all recursive data types, lists are usually represented using pointers. Each 
element in an a list consists of a record with two fields. The first field is a value of type 
a; the second field is a pointer to the head of the rest of the list. Thus, the list L1 = 

[1,2,3] could be represented as shown in Figure 34(a). 

Polymorphic functions operating on lists, however, are compiled to be 
independent of the type of the list elements; the polymorphic list reversal function of 
Figure 4, for example, manipulates individual list elements independent of their type. 
Subsequently, those elements must be boxed. The standard boxed representation for the 
list [1,2,3] is shown in Figure 34(b). 

But list elements are not always atomic objects. Figure 34(c) shows a flat, 
unboxed representation of a list composed of three pairs where each element of the list 
is a pointer to a pair and each pair is represented in the unboxed form discussed in the 
previous section. This representation is acceptable for functions such as reverse, of 
typea list -> a list, but consider the polymorphic function unzip [ShA95], of 
type (a*B) list -> a list * B list shown in Figure 35. It operates on lists 
of type (a*B) list, returning a pair of lists, the first of type o list, the second of type 
B list. The application of unzip to the list [ (1,4), (2,5), (3,6) ] results in the 
par ({1,.2,3],-[4, 5,6] )« 
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Ll es 
L2 [(1,4), (2,5), (3,6) ]; 


ig eg NO BE Cd 


(a) Flat Unboxed Representation of Ll 


(b) Standard Boxed Representation of Ll 


(c) Flat Unboxed Representation of L2 


cag A I a OR cs ES a Ld 
Ee PERG RAEES SEATED 


(d) Standard Boxed Representation of L2 





Figure 34. Data Representations for Recursive Types. From [ShA95]. 


The flat representation of Figure 34(c) is not suitable for function unzip, as 
unzip manipulates the individual fields of the pairs comprising the elements of the list. 
For unzip to work, those fields must be boxed, leading to the standard boxed 
representation of Figure 34(d). On the same theme, one could imagine having lists of 
lists of pairs of lists, etc., and could construct polymorphic functions, such as an 


imaginary super unzip, that require the entire construct to be boxed. Obviously, if 
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lists were stored in a flat representation, the boxing and unboxing required for such 


polymorphic function calls could be very expensive. 


fun unzip l 
jet fun h a2 = h(r,a::u,b::w) 


everse u, reverse w) 





Figure 35. Unzip Function in ML. From [ShA95}. 


For this reason, it is appropriate to store and maintain recursive structures in 
standard boxed form at all times. Doing so complicates access to, and manipulation of, 
these structures but it is relatively inexpensive. In the case of lists, for example, 
appending a new element to the head of a list is simple. The new element is boxed and 
inserted at the front of the linked list of elements. 

Thiemann proposes a revised translation scheme utilizing continuation-passing 
style and a notion called representation types [Th95]. A result of his work is that many 
recursive data structures can have more efficient storage representations. These 


techniques might be applicable to extensions of Polymorphic C. 


E. EFFICIENCY AND OPTIMIZATION 

The most significant result of the work reported in [Le92] is the successful 
introduction of mixed data representations to ML via simple program translations and the 
introduction of wrap and unwrap operators. In experiments which compared the 
performance of a compiler utilizing mixed representations and the coercion scheme 
discussed above to that of an identical compiler using the traditional uniform 
representation, the former was clearly superior in most instances. 

The best results were achieved on programs that performed a great deal of integer 


and floating point arithmetic, involved a significant amount of looping, and/or performed 
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a significant number of function calls. These results are due to the fact that much of the 
code in any real program is monomorphic and, hence, benefitted from the ability to 
directly access data in its optimal representation. 

There was no significant difference for programs which performed a great deal of 
list processing. This, too, makes sense in that the representation of lists is the same in 
both cases. 

The worst results came from programs which utilized a great deal of 
polymorphism. The reasons for this are also clear. The coercions required for a 
polymorphic function call can be quite expensive in some instances. 

The results reported by [Le92] are obtained by applying the proposed 
implementation scheme without additional optimizations. Of the many possible 


optimizations, the following seem to be the most promising. 


1. Compile-time Reductions 
There are three important cases, all somewhat related, in which static analysis of a 


program can result in the elimination of a number of unnecessary coercions. 


a. Elimination of Trivial Coercions on Data 

Any sequence of calls of the form wrap (unwrap (x) ) or 
unwrap (wrap (x) ) are trivial and can be replaced with x. Consider the example of 
Figure 36, for example. 

The rules for passing unwrapped objects via quantified formal parameters 
were clear: wrap the actual parameter before the call and, if necessary, unwrap the return 
value after the return. A naive implementation might analyze the code of Figure 36(a) 
and, based on that rule, mechanically generate the translation of Figure 36(b). It’s clear, 
however, that one unwrap operation and one wrap operation can be saved by eliminating 


the trivial coercions prior to the second application of id. The resulting code is shown in 


Figure 36(c). 
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apply(f, 


one id(tappliy(id, 1) )3 


one unwrap (id(wrap(unwrap(apply(id, wrap(1)))))); 


one unwrap (id(apply(id, wrap(1)))); 





Figure 36. Elimination of Trivial Coercions. 


b. Use Inline Monomorphic Functions 

When a monomorphic function is applied to wrapped values, an envelope 
function must be inserted around the monomorphic function to unwrap its parameters, 
call it, and wrap its return value. If the monomorphic code is sufficiently small, inlining 


that function would save function call overhead. 


Cc. Monomorphic Expansion 

If polymorphic functions are consistently replaced by specialized functions 
for each instance of application on a new type, the program becomes strictly 
monomorphic. In this case, polymorphic functions would be used similarly to Ada 
generic functions or C++ templates: they would merely serve as templates for the 
creation of monomorphic code. The compiler would be free then to generate optimal data 
representations for all types. 

While we have noted that the growth of code could be enormous if many 
diverse functions are applied to data of many types, there are some advantages to this 
approach, especially using the implementation scheme discussed in this chapter. First, 
the code growth in any particular instance may be manageable for a particular program. 

If it is not, it is possible to monomorphically expand only a portion of the code - perhaps 


a particular, high-performance set of functions - while leaving the rest unexpanded. 
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The ability to selectively perform this sort of time/space optimization is a 
primary strength of this technique. Thiemann provides additional thoughts on this matter 
[Th95]. 


Z. “Don’t Care” Polymorphism 
Thiemann notes an extremely simple optimization which he terms “Don’t 
Care” polymorphism [Th95]. It can be fully explained by an extremely simple example. 
Given a function first (x,y) = x, of type (a*B) —> a, it does not matter if y is 
wrapped or unwrapped; it is ignored. Since the function does not need to access y, it 


need not be coerced under any circumstance. 


3. Proper Use of Tail Recursion 
Thiemann notes an optimization somewhat related to the case of eliminating 
trivial coercions [Th95]. Consider, once again, the function apply and the application 


apply(succ, 1). Using inline notation, this application is translated to: 
unwrap (apply (Ax.wrap (succ(unwrap(x)))), wrap(1)); 


After the application of succ to the unwrapped integer, the return value is wrapped by 
the envelope function and returned to apply where it is immediately returned to the 
calling routine and unwrapped. 

Under these circumstances, there is no need for the envelope function to wrap the 
object prior to the return; the polymorphic function apply does nothing with it after the 
return except return it to the monomorphic routine which, in the end, wants it in 


unwrapped form. The techniques in [Th95] eliminate this inefficiency. 
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V. IMPLEMENTATION RECOMMENDATIONS FOR 
POLYMORPHIC C 


This chapter discusses the implementation of polymorphism in Polymorphic C. 
Section A reviews the primary issues raised in the case studies of Chapters III and IV. 
Section B presents a recommendation for Polymorphic C. Section C demonstrates how 
one might achieve the effect of parametric polymorphism in an imperative language by 
repeating the examples of Chapter IV using C. Section D concludes the chapter with 
examples of potential translations, a la [Le92], from Polymorphic C to a target language 


(Polymorphic C augmented with the wrap and unwrap constructs). 


A. REVIEW OF IMPLEMENTATION TECHNIQUES 

This section briefly reviews some of the implementation decisions covered in 
previous chapters with the goal of narrowing the scope of choices for Polymorphic C. 

In the implementation of parametric polymorphism, polymorphic functions must 
be compiled to operate on data that is represented in some uniform form. This 
requirement can be accommodated by representing all data in a system in a uniform form, 
as is done in ML, but doing so significantly reduces the efficiency of monomorphic code. 
This has a significant overall impact on a program since monomorphic code usually 
comprises 80 - 90 % of the total in a typical program. 

A better approach is to store and manipulate values in their optima! concrete 
representations and convert them to a uniform form only when required in order to 
accommodate polymorphic functions. Regardless of how it is accomplished, this 
conversion can only occur at one of two points: before the call to a polymorphic function 
or after the call to a polymorphic function. Napier88 takes the latter approach, [Le92] 


the former. 
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I. Conversion After the Call. 

This choice is forced because Napier88 supports both type specialization without 
call and first-class functions. Hence, the compiler is not able to determine statically 
whether a function being called will be polymorphic or monomorphic at run time. The 
only efficient alternative is to leave data in concrete form and allow the function, if it is 
polymorphic, to itself convert the data to uniform form and reconvert it to concrete form 
prior to return. 

However, this conversion scheme demands that the polymorphic function be 
supplied with the type information it will need in order to perform the appropriate 
conversions. If the data is of some compound type, it must also be supplied with 
information regarding the structure of the data. There are three ways to accomplish this. 
The first is to simply pass this information as separate parameters to the polymorphic 
function. The second is to tag data with type information. 

The third, used in Napier88, is to create an envelope function and store the type 
and structure information in variables local to that function. The polymorphic code is 
then dynamically bound to the envelope function, making those local variables visible to 
the polymorphic function which can exploit that information to perform the correct 
conversions. On subsequent specializations, the polymorphic function is bound to 
different envelope procedures with different values in the local variables, resulting in 


different conversions. 


Zz. Conversion Before the Call 

The approach used in Napier88 is not applicable to ML. First, functions in ML 
are statically bound at time of definition so we are not able to dynamically re-bind 
polymorphic functions to different envelope functions. Therefore, to convert after the 
call we must either pass type and structure information via separate parameters or use 
tagged data. 

Secondly, ML does not support type specialization. This means that the compiler 


is able to statically type the entire program. Hence, the requirement to delay conversion 
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until after the call to a polymorphic function does not exist; we are free to convert values 
prior to the call. This is the approach adopted in [Le92]. In this case, the data is 
converted from within an environment where type and structure information is known; 
there is no requirement to somehow propagate this information to the polymorphic 
function. 

The only difficulty with this conversion scheme occurs when a polymorphic 
function must apply a monomorphic function to its data (e.g., a polymorphic sort routine). 
The monomorphic function expects to receive its data in concrete form but the 
polymorphic function does not know how to perform the proper conversions. This 
problem is solved in Leroy’s method by creating an envelope function which performs 


the conversions then applies the monomorphic function to the converted values. 


B. APPLICABILITY TO POLYMORPHIC C 

Polymorphic C is a strongly and statically typed language. As such, it shares the 
same implementation constraints as ML. Because Polymorphic C is statically typed, the 
implementation technique used in Napier88, which relied on dynamic binding, is not 
applicable to Polymorphic C. 

We are free to convert either prior to or after the call to a polymorphic function, 
with the only concern being that of implementation efficiency. There are several clear 
alternatives which are outlined in Figure 37. 

The most efficient of the alternatives is to convert values to uniform form prior to 
the call to a polymorphic function. This will lead to the overhead associated with 
envelope procedures, but only in the case where monomorphic code is applied to data 
represented in uniform form. In all other cases, the overhead imposed by this scheme is 


limited to that required to perform the conversions. This method is that given in [Le92]. 
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. Conversion After the Call 
a. Pass Type and Structure Information via Additional Parameters 
Imposes additional function call overhead for every polymorphic function 
in the system. 
Use Tagged Data 
Imposes additional complexity and overhead for the entire system, whether 


polymorphic or not. 


. Conversion Before the Call 
a. Create Envelope Functions For Monomorphic Functions 
Imposes additional function call overhead only when monomorphic functions are 
applied to uniform values. 





Figure 37. Implementation Alternatives for Polymorphic C. 


C. SIMULATING PARAMETRIC POLYMORPHISM IN C 

Leroy’s translation works by automatically inserting appropriate coercions 
whenever polymorphic functions are specialized. Since C does not support type 
abstraction (i.e., all types are concrete), one cannot actually apply Leroy’s translation to C 
source code. However, it is possible to achieve the same effect by manually introducing 
coercions that correspond to those introduced when the translations are applied to 
equivalent functions in ML. 

One first needs to define the uniform representation to be used in C. Since 
pointers are typed in C, the boxing of a value results in a pointer to a specific type. 
Hence, we must not only box the objects but also coerce the results to or from a specific 
pointer type. The choice of type is unimportant as long as it uniform and consistent. 

We have arbitrarily chosen the pointer to void (void*) as the uniform data 
representation. Wrapping is performed by referencing an object and casting the result as 
a pointer to void. Unwrapping is performed by casting a pointer to void to a pointer of 
the appropriate type and dereferencing the result. An unwrapped integer value x, is 


wrapped by the operations (void*) &x. A wrapped integer value y, is unwrapped by 
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the operations * (int*) y. These operations may be encapsulated; the wrap and 


unwrap functions for types int and float are shown in Figure 38. 


vVo1ld* wrap. 1nt {int <¢¢c) {return (vo1d*) 4c; } 
void* wrap float(float &c) {return (void*) &c;} 


int Unwrap int (void: *u) {return * (int) U7) 


float unwrap float(void *u) {return * (float*)u;} 





Figure 38. Wrap and Unwrap Functions in C. 


The discussion continues in two parts. We review some examples of how 
parametric polymorphism might be achieved in C and conclude with a discussion of how 


this might be improved. 


1. Examples 
We repeat here the examples of Chapter 1V. The equivalent ML code from 
previous examples is included as comments immediately preceding the corresponding C 
code. The wrap and unwrap functions shown in Figure 38 are contained in the file 
“wrpunwrp.h”’. 
a. Polymorphic Identity Function 
The polymorphic identity function of Figure 27 is coded in C as shown in 
Figure 39. As can be seen, there is a clear mapping between the ML and C code. 


b. Polymorphic Function “first” 


The polymorphic function first of Figure 28 is coded in C as shown in 
Figure 40. While still quite simplistic, the call id (x) within first does serve to 
demonstrate the passing of a quantified actual parameter via a quantified formal 


parameter. 
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#include “wrpunwrp.h” 


// fun id(x) = x; 
void* id(void *x) {return x; } 


void main () 


{ 
// val one = unwrap(int) (id(wrap(int) (1)))); 
int one = unwrap_int(id(wrap int(1))); 


} 





Figure 39. Polymorphic Identity Function. 


#include “wrpunwrp.h” 


// fun id(x) = x; 
void* id(void *x) {return x;} 


Jf £un: LTirst(x, Vy) - = adits)? 


void* first(void *x, void *y) {return id(x) ;} 


void main () 

{ 
// val a = unwrap(int) (first (wrap (int) (1),wrap(float) (2.0))); 
int a = unwrap int(first(wrap_int(1), wrap float(2.0))); 





Figure 40. Polymorphic Function “first” in C. 


c Polymorphic Higher-Order Function “Apply” 

The higher-order function apply of Figures 29-31 is coded in C as shown 
in Figure 41. Note that the use of a function pointer, * PF’, is required in the call to 
apply because C does not allow higher-order functions. 

Also note the function succ_prime which represents the wrapped 


version of succ. The use of this function is required because C does not allow nested 
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function declarations. In other words, there is no C equivalent of the ML expression 
apply (Ax.wrap(int) (succ(...)), ...) of Figure 30. Rather, we must 
mirror the construct of Figure 31, where the anonymous lambda abstraction was given a 


name, succ’, and called explicitly as follows: apply (succ’, ...). 


#include “wrpunwrp.h” 


// fun succ(x) = x + I; 
int succ(int x) {return x + 1;} 


// = suce’ = kx.wrap(int) (succ (unwrap (int) (x))) 
void* succ prime (void* x) 
{ 


return wrap int (succ (unwrap (x) ) ) 


} 
typedef void* (*PF) (void*) ; 


// fun apply(f, x) = £(x); 
void* apply (PF £f, void *x) {return f(x) ;} 


void main () 


{ 


// let two = unwrap int (apply(succ’, wrap(int) (1))) 
int two = unwrap int (apply(succ_prime, wrap_int(1))); 





Figure 41. Polymorphic Higher-Order Function “Apply” in C. 


d. Polymorphic Function “mkPair” 

The polymorphic function mkPair of Figure 32 is coded in C as shown in 
Figure 42. We demonstrate two ways to implement the function application, both of 
which are also shown in Figure 32. 

Since C does not have predefined pairs, we start by declaring structures 


that mimic the pairs of ML. The structure floatPair is the flat unboxed 
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representation for a pair of floats; polyPair is the standard boxed representation for a 
pair of anything. 

In the actual code, there are only two notable differences. The first is the 
use of a temporary variable, pp, inmkPair; in C, one cannot have a constructor as the 
right-hand side of a return statement. The other is the use of a global variable, x, in the 
first call to mkPair; in the ML code, the variable is local to the call. Both of these 


differences are artifacts of C and are not inherently associated with imperative languages. 


#include “wrpunwrp.h” 


struct floatPair {float fst; float snd;}; 
struct polyPair {void *fst; void *snd;}; 


// fun mkPair(x) = (x,X); 
polyPair mkPair(void *x) 
{ 
polyPair pp = {x,x}; 
return pp; 


} 


void main () 
{ 
// val realPair = 


jf let x = mkPair(wrap(float) (3.14)) 

Vi in (unwrap (float) (fst (x)), unwrap(float) ((snd(x))); 

polyPair x = mkPair(wrap_ float (3.14)); 

floatPair realPair = {unwrap float(x.fst), 
unwrap float (x.snd) }; 


// val realPair = 
(unwrap (float) (fst (mkPair (wrap (float) (3.14))), 
// 


unwrap (float) (snd(mkPair (wrap (float) (3.14))); 
floatPair realPair2 = 
{unwrap float (mkPair(wrap_float(3.14)).fst), 
unwrap float (mkPair (wrap float(3.14)) .snd)}; 





Figure 42. Polymorphic Function “mkPair” in C. 
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2. Discussion 

The previous examples demonstrate that explicit coercions can be used to achieve 
parametric polymorphism in C. However, there are difficulties, not the least of which 1s 
that the programmer must correctly manage the complexity associated with these explicit 
coercions with little or no help from the compiler. For example, there is nothing in C’s 
type system to prevent the programmer from performing inadvertent casts such as 
float f = unwrap float (apply(succ_prime, wrap_int(x))); 

A second difficulty is that the programmer must explicitly deal with the 
polymorphic nature of a function to begin with. In the case of app1y, for example, 
he/she must insert the proper coercions when app1y is called and must also explicitly 
generate the envelope function succ_prime. Not only does this decrease programmer 
productivity and introduce additional sources of error, it also implies some knowledge of 
the body of apply and of the fact that succ_ prime has not yet been coded by some 
other programmer. These observations may seem trivial for this toy example but, in the 
context of a large development effort, it is not clear that a programmer will have this 
knowledge. 

A better approach would be to design an imperative language and a set of 
appropriate translations such that these coercions and envelope procedures could be 
automatically generated if and when they are needed. The programmer would then be 
relieved of the burden associated with simulating polymorphism. 

If that language also supported type inferencing, entire programs could be written 
without any explicit type information at all. Figure 43(a) shows how the C source code 
of Figure 41 might be improved in an imaginary language which resembles C without 
explicit type information. With no further assumptions, it would be possible for a 
compiler to use the method proposed in [Le92] to translate the call to apply as shown in 
Figure 43(b). 

This hypothetical language corresponds to Polymorphic C. 


if 








succ{x) {return x + 1;} 
apply(f, x) {return f£(x);} 


void main(){two = apply(succ, 1);} 


succ prime(x) {wrap int(succ(unwrap int(x)));} 
two = apply(succ prime, wrap(1)); 





Figure 43. Code Without Explicit Type Information. 


D. LEROY’S METHOD APPLIED TO POLYMORPHIC C 

One of the great strengths of the method under consideration is that the coercions 
inserted into function calls are based exclusively on the types of the functions involved. 
They are completely independent of the body of the function. For example, the call 
foo (x) for any function foo of type a —> a, whether foo is the simple identity 
function or one of extreme complexity, is translated to a call of the form: 
unwrap (Tt) (foo (wrap (t) ). Likewise, the call bar(f, x) for any function bar 
of type (a —> B) * a —> B is translated to a call of the form: 
unwrap (tT) (bar (Ay.wrap(t) (f (unwrap (Tt) (y))) ,wrap(t) (x) )) 

This makes the application to Polymorphic C relatively straightforward. If the 
target language of the translations is Polymorphic C augmented with wrap and unwrap 
operations, the results would be identical to those seen in ML and simulated in C. 

Two simple examples will suffice. Figure 44(a) gives the Polymorphic C version 
of the polymorphic identity function and an application of that function. The resulting 


translation of the call is shown in Figure 44(b). 
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in 
1a(3) 


unwrap (id(wrap(3) ) 





Figure 44. Polymorphic Identity Function in Polymorphic C. 


Figure 45(a) gives the Polymorphic C versions of the integer successor function, 
succ, and the polymorphic, higher-order function apply, and an application of apply 


to succ and the integer 1. The translation of the call is shown in Figure 45(b). 


(a) let succ = Ax.x + 1 
in 
let apply = Af,x.f(x) 
i} 
apply(succ, 1) 


let succ’ = Ay.wrap(succ (unwrap (y) ) 
in 
unwrap (apply(succ’, wrap(1))) 





Figure 45. Higher-Order Function “apply” in Polymorphic C. 
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VI. FURTHER RESEARCH 


While the approach presented in [Le92] shows great promise for the 
implementation of polymorphism in Polymorphic C, there is much work remaining 


before such an implementation can be fully realized. 


A. TRANSLATION RULES 

The first step in such an effort must be to formulate a set of translation rules based 
on the type system of Polymorphic C which can be used to insert the proper coercions 
into the function calls. Since these coercions are generated based on the type, vice the 
syntax or structure, of the functions, the translation should as in [Le92]. 

Polymorphic C does include two data types not seen in the core ML considered in 
[Le92]. It includes pointers of type t.pfr, and arrays. The introduction of pointers should 
not present great difficulty because they would not have to be coerced. The values 
attained by dereferencing pointers might have to be coerced but this, too, should be 
amenable to translation from the typing rules. Likewise, arrays can be handled easily if 


maintained in standard boxed representation at all times. 


B. DATA REPRESENTATIONS 

A decision will have to be made concerning the proper data representation for the 
various data types. At present, the only concrete atomic data types in Polymorphic C are 
integers and pointers to integers. The only data structures are arrays. Any 
implementation decisions made now regarding data representations should anticipate the 
eventual introduction of additional atomic types such as reals and characters and of data 
structures such as structures and lists. Thiemann presents some techniques which might 


be applicable to future extensions to Polymorphic C [Th95]. 
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C. TYPELESS RUN TIME SYSTEM 

Given that Polymorphic C is strongly and statically typed, there can be no type 
insecurities at run time for a properly compiled program. It may be possible to devise a 
run time system which utilizes this assurance to improve the efficiency of the 
implementation. Pederson has investigated parameter passing methods using direct 
manipulation of the run time stack to preclude unnecessary coercions [Pe95]. His results 


would be applicable to a large number of language implementations. 
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APPENDIX 


This appendix provides a somewhat detailed treatment of the implementation 
method presented in [Le92], which allows ML to be compiled with mixed data 
representations. The discussion borrows heavily from that work. Section A provides a 
formal description of the system. Section B provides translations for the examples shown 


in Chapter IV. 


A. FORMALIZATION 

The method presented in [Le92] consists of a translation from a source language 
to a target language. The source language is core ML. The target language is core ML 
augmented with the two constructs wrap(t) and unwrap(t). The syntax is shown in 
Figure Al, where x is an identifier, i is an integer constant, fis a floating point constant 


and a is a type variable. 


Source terms: a::=i|f|x|Ax.a|letx =a] ina? | aj(a2) | (aj, a2) | fst(a) | 
snd(a) 


Target terms: a’::=i|f|x|Ax.a|letx =ajz ina? | aj(az) | (aj, a2) | fst(a) | 
snd(a) 


| wrap(z)(a@’) | unwrap(z)(a’) 


Type expressions: 7::= a@| int | float | 77 —> 72 | 7) x 72 


Type schemes: O::= Vay...ay.T 





Figure Al. Target Language Syntax. From [Le92]. 


Type inferencing is performed by applying Milner’s type discipline to the source 


language. While we will not concern ourselves here with type inferencing, the typing 





rules are important due to the similarity with translation rules introduced next. The 


typing rules are shown in Figure A2. The predicate Ea x:t is read as “under 





assumption £, term a has type t”. The construct ae is read “(A and B) implies C”. 


E(x)=Va,...a,.T Dom(p)c {a@,...a,, 
Eka x: p(t) 


E+>i:int [3] Etry f: float 


E+x:7,ha:t, 
ERAX.a:T,->T, 


Ewa,:t,7>t, Epya,:t, 
Et a,(a,): 7, 


[5] 


6] Et~a,;t, Era,:t, 


EW (a,,a,):7, xT, 
Epa:t,xt, 18] Ewa:t,xt, 


iN = 7 7 
+» fst(a): 7, E+} snd(a): 7, 


19] Ewa,:t, E+x:Gen(t,,£E)Ra,:T, 
Et let x =a, ina, :T, 





Figure A2. Typing Rules for Core ML. From [Le92]. 


Once the type system has established a typing for a term and it’s sub-terms, the 
translation rules of Figure A3 are applied. The translation is presented as the predicate 
Et) x:t= a’, which is read as “under assumption E, term a has type ¢ and is translated 
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to the term a’”’. 
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a 





E(x)=VaQ,...a@,.7 Dom(p)¢ {a@,...a,} 
Etex: p(t) >8,(x:7) 


Ewi:int>i [T3] Eh f:float=> f 


E+x:7,ha:t, >a! 


ERAX.A:T, 97,24 %.a' 


ERayit, 77, >a, EwWa:it,>a', 
EW a,(a,):7, >a’, (a’',) 


. ' ° ' 
ERa3;t,;>a'’, Era,:t,>a', 
Er (@,,4,):T, x T, > (a, ,a',) 


EWPa:t, xt, >a TS] EWait,xt,>a' 
E } fst(a): 7, => fst(a’') E+ snd(a): 7, => snd(a') 


Etya,:t,; >a, E+x:Gen(t,,£)ba,:t, >a’, 
E} let x =a, ina, :t, => let a’, ina’, 


Figure A3. Translation Rules. From [Le92]. 


The heart of the translation is seen in the rule [T1] which is the rule for type 
specialization. FE is the environment, a mapping from identifiers to type schemes and p is 
a of types for type variables. Loosely translated, the rule [T1] says: if there exists in E a 
mapping from some identifier x to some type scheme Va,...a,, and the types a...a, are 
type variables in the domain of p, then x has a type defined by replacing each occurrence 
of the type variable t with the type to which t 1s mapped in p and is translated by 
applying the transformation S,. 

We shall return to the S transformation. For now, consider the concrete example 
of Figure A4 which shows the process by which a polymorphic, higher-order function is 


specialized. Initially, E and p are both empty. When the integer successor function, 





succ, is defined, identifier succ is added to the domain of E and is associated with the 
type int -> int. When the function app1y is defined, the process is repeated for 
identifier apply and the type (a —> B) * a —> 8. Variable anInt is handled likewise. 
When app 1y is applied to succ and anInt, the type system is able to infer that 
both « and 6 are both of type integer for this application; this mapping from type 
variables to types for a given application is what p represents. As a result, apply is 


assigned the type (int -> int) * int -> int for this application. 


a 
= 


fun suce(x) = x + 1; 
BE ={succ int -> int} 
p ={} 


fun apply(f,x) = £ (x); 
E ={succ >int -> int, apply >(a-—>f)*a-—-> 6} 


ota 


val x = 1; 
E ={succ >int -> int, apply >(a—->8)*a->8, x => int} 
Pp =4} 


val y = apply (succ,x) ; 
E ={succ >int -> int, apply >(a—-B)*a-—-6, x => int} 
p ={a> int, B=> int} 





Figure A4. Mappings of E and p. 


The work of the translation is performed by the transformations S and G, shown in 
Figures A5 and A6. In our example, translation rule [T1] invokes the translation S,(x:t), 
where x is the function apply and 1 1s the type (int->int) *int->int. 

In the notation of the translation rules, a’ = x. We first apply S transformation rule [S5], 


where a’= apply,t, = (int->int)*int,andt2 = int, resulting in the term 
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Ax. Sp(apply (Gp(x: (int->int)*int)):int). The rest of the transformation 


is straight forward and is shown in Figure A9. 


[S1] Sp(a’: a) = unwrap(p(a))(a@’) 


[S2] Sola’: int) =a’ 
[S3] Sela’: float) =a’ 
[S4] Sola’: t] x 72) = let x =a’ in (Secfst(x) : 77), Seo(snd(x) : 72)) 


[S5] Sola’: t] —> 72) = Ax.Sp(a'(Gp(x : t7)) : 72), where x is not free in a’ 





Figure A5. S Transformations. From [Le92]. 


[G1] Gola’: a) = wrap(p(a))(a’) 
[G2] Gola’: int) =a’ 


[G3] Gola’: float) = a’ 


[G4] Gola’: t] x T2) = let x =a’ in (Ge(fst(x) : 77), Ga(snd(x) : 72)) 


[G5] Gola’: tT] —> 72) = Ax.Se(a’(Sp(x : 77)) : 72), where x is not free in a’ 





Figure A6. G Transformations. [From Le92]. 
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B. TRANSLATIONS 

The following translations are provided for examples given in Chapter IV. In 
Figures A7 through A10, part (a) displays the source code, part (b) displays the function 
application which invokes the translation, part (c) shows the translation as derived from 


the translation and transformation rules of Section A, and part (d) shows the final results. 


fun id(x) = x; 
val one = id(l); 


EW id:int>int=>Sp(id:a>oa) Enwtl:nt>1 


Er id(1) : int = Sp(id: a > a\(1) [15], (11) [73] 


Solid : a —> a) = Ax.Sp(id(Getx : int)) : int) [S5] 


= 2x.Sp(id(wrap(int)(x)) : int) [G1] 


= Ax.unwrap(int)(id(wrap(int)(x))) [S1] 


id(1) = unwrap(int)(id(wrap(int)(1))) 





Figure A7. Translation of Polymorphic Identity Function (see Figure 31). 
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fun id(x) = x; 
fun first(x,y) 


| val a = first(l, 





E ® first : int x float > int > Spo(first :a@ x B > a) 
Evi l:int>1 


E+ 2.0: float => 2.0 
E' + first(1, 2.0) : int => Sp(first : @ x B—> a)(1, 2.0) 


[TS], [T1], [T2], [T3] 


So(first: a x B —> a) =Ax.Sp(first(Ge(x : int x float)) : int) [S5] 
= Ax.Sp(first(let y = x in (Gp(fst(y) : int), Gp(snd(y) : float))): int) [G4] 
= 1x.So(first(let y = x in (wrap(int)(fst(y)), wrap(float)(snd(y)))) : int) [G2], [G3] 


= XX.unwrap(int)(first(let y = x in (wrap(int)(fst(y)), wrap(float)(snd(y))))) [S1] 


(a) 
first(1,2.0) = unwrap(int)(first(let y = (1,2.0) in (wrap(int)(fst(y)), wrap(float)(snd(y))))) 


or, equivalently: 


first(1,2.0) = unwrap(int)(first(wrap(int)(1), wrap(float)(2.0))) 





Figure A8. Translation of Polymorphic Function First (see Figure 32). 
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(a) fun succ(x) = x + 
fun apply(f, x) = 


(b) val two = apply(succ, 1); 


E » apply : (int > int) x int > int > Sp(apply : (a > B) x a> £) 
E+ succ : int > int => succ 
Erit:nt=>1 


ee) PTS], (TH, 
E + apply(succ, 1): int > sp(apply : (a > B) x a > B)(succ, 1) 


[T2] 
So(apply : (a —> B) x a —> B) = Ax.Sp(apply(Getx: (int —> int) x int)): int) [S35] 
= Ax.Sp(apply(let y = x in (Gp(fst(y): int —> int), Gp(snd(y): int))): int) [G4] 
= Ax.Sp(apply(let y = x in (Gp(fst(y): int —> int), wrap(int)(snd(y)))): int) [Gl] 
= Ax.Sp(apply(let y = x in (Az.Ge(fst(y)(Se(z: int)): int), wrap(int)(snd(y)))): int) [G5] 


= Ax.Sp(apply(let y = x in (Az.Gp(fst(y)(unwrap(int)(z)): int), wrap(int)(snd(y)))): int) [$1] 
= Ax.Sp(apply(let y = x in (Az.wrap(int)(fst(y)(unwrap(int)(z))), wrap(int)(snd(y)))): int) [G1] 


= Ax.unwrap(int)(apply(let y=x in (Az.wrap(int)(fst(y)(unwrap(int)(z))), wrap(int)(snd(y))))) 
[S11] 


(d) 
apply(succ, 1) = unwrap(int)(apply(let y = (succ, 1) in (Az.wrap(int)(fst(y)(unwrap(int)(z))), 
wrap(int)(snd(y))))) 


= unwrap(int)(apply(Az.wrap(int)(fst(succ, 1)(unwrap(int)(z))), wrap(int)(snd(succ, 1)))) 
= unwrap(int)(apply(Az.wrap(int)(succ(unwrap(int)(z))), wrap(int)(1))) 


= unwrap(int)(apply(succ’, wrap(int)(1))), where succ’ = Az.wrap(int)(succ(unwrap(int)(z))) 


Figure A9. Translation of Higher-Order Function Apply (see Figures 33 - 35). 
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fun mkPair(x) = (x, x); 


val realPair = mkPair(3.14); 


E }» mkParr : float > float x float > So(mkPair : a > @ x a) 
Eb 3.14: float => 3.14 
E + mkPair(3.14) : float => sop(mkPair : (@ > @ x a@)(3.14) 


[TS], [T1], [T3] 


So(mkPair : a —> axa) = Ax.Sp(mkPair(Go(x: float)): float * float) [S5] 
= Ax.Sp(mkPair(wrap(float)(x)): float x float) [Gl] 
= Ax.let y = mkPair(wrap(float)(x)) in (Sp(fst(y): float), Sp(snd(y): float)) [S4] 


= Ax.let y = mkPair(wrap(float)(x)) in (unwrap(float)(fst(y)), unwrap(float)(snd(y))) [S1] 


(d) 


mkPair(3.14) = let y = mkPair(wrap(float)(3.14)) in (unwrap(float)(fst(y)), 
unwrap(float)(snd(y))) 


or, equivalently 


mkPair(3.14) = (unwrap(float)(fst(mkPair(wrap(float)(3.14)))), 
unwrap(float)(snd(mkPair(wrap(float)(3.14))))) 





Figure Al0. Translation of Polymorphic Function mkPair (see Figure 37). 
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